en/static/graph.toml

#:schema ./graph-schema.json

root_node = "Start"

[nodes.Start]
text = """
## What is en?

en is a writing tool. It was designed with complex, conceptually heavy projects, where the relationships between terms matter and possibly have their own attributes. You can use it to write non-linear, connected textual works and have their references to which other mapped out as a |graph| of metadata-rich, interrelated information. This very website is running en.

It works by ingesting plain text files written in |TOML|, a file format that focuses on being human-readable but that can also be directly interpreted by computer programs. These files contain your node definitions and allow en to construct a human-readable website that makes your graphs' nodes browsable, searchable and listed in relation to each other or as a shallow tree of nodes. It also serves this graph as raw data for integration with other tools that can further analyze and transform what you have written.

## Motivation

en was created out of the desire to write a web of encyclopedic-style long-form texts documenting a personal worldview. It aims to remove the constraints imposed by trying to mimic the linearity of a typical nonfiction book.

It's described as a "writing instrument" because it's not so much about the presentation or even the web format. While that's the medium for this particular implementation, you can notice en serves its raw data in both TOML and JSON. It's first and foremost about mapping out and structuring written thoughts.

Because your en graph is defined in simple plain-text files, you can add new pages easily from a few lines and start connecting them. Instead of having to create a dedicated file or resource for each new entry you find deserving of observation, with its own beginning and end, its own "I'm empty, fill me to completion" demeanor, you can stay in the flow of your sprawling thoughts. This is meant to fit the specific wiring of minds whose thoughts spread and fork quickly and often, whether to great depth or across wide expanses.

## What's ahead

en is in its infancy. Right now, most of the work is focused on making the markup syntax more robust. Some interesting features planned include:

- Multi-file graphs, including single-file node definitions with TOML frontmatter
- Richer node connection metrics and sorting
- Builtin and custom connection kinds with special rendering styles
- More render formats: static website, single page and PDF/EPUB formats
- JSON schema for language server integration
- Full-text search

If you like what you see and are curious about en's future, take a look at the |roadmap| for a more comprehensive outlook of what else is to come.

## Get started

See the |GetStarted| page to learn how to install and use en
"""

[nodes.GetStarted]
title = "Get Started"
text = """
## Installation

### Pre-built binaries

The easiest way to get started is by downloading a pre-built binary.

x64 Linux binaries are available from the |git.jutty.dev package registry|https://git.jutty.dev/jutty/-/packages/generic/en|:

%
    Platform        ! Download
    x64 Linux GNU   | |en-x64-linux-gnu|https://git.jutty.dev/api/packages/jutty/generic/en/{{ en_version }}/en-x64-linux-gnu|
    x64 Linux musl  | |en-x64-linux-musl|https://git.jutty.dev/api/packages/jutty/generic/en/{{ en_version }}/en-x64-linux-musl |
%

If in doubt, it is likely your system uses the GNU libc. Regardless, the musl binary is statically compiled and should run on mostly any x64 Linux system.

Other platforms may be supported in the future depending on CI resources.

### Build from source

If you are on another platform or simply prefer starting from source, you can also build en yourself.

You will need:

- For en itself, a |Rust compiler|https://rustup.rs/
- For dependencies, a C compiler (e.g. `gcc`)

Given the above is satisfied, you can build directly through Cargo:

`
cargo install --git https://codeberg.org/jutty/en --tag v{{ en_version }}
`

And you should now have the `en` command available on your shell.

The `cargo install` example shown above will build en from the last tagged release, which should be more stable. You can remove the `--tag v{{ en_version }}` part if you'd like to build the most recent development sources.

For more details on building from source, see |SourceBuild|.

## Usage

Once you have installed en, run it and point it to your graph:

`
en --graph my-graph.toml
`

See |CLI| for defaults and details on the available options.

## Graph Syntax

The graph is a |TOML| file. You can create nodes by adding text such as:

`
[nodes.Computer]
text = "A computer is a machine capable of executing arbitrary instructions."
`

If you need longer text, it's more convenient to use triple quotes:

`
[nodes.Computer]
text = \"""
A computer is a machine capable of executing arbitrary instructions.

The main electronic component of a computer is its |motherboard|.
\"""
`

In |the future|Roadmap, en should support both individual node files with TOML frontmatter and also multiple TOML files containing several nodes each. In the current implementation, all nodes live in a single `graph.toml` file.

Some special syntax is allowed inside the node text. See |Syntax| for supported features.

A node can have several other attributes. See |Node| for details on all of them.

### Connections

Nodes can have connections between each other. Each node page lists its outgoing and incoming connections.

The simplest kind of connection is achieved by creating an anchor to another node in the node text itself:

`
[nodes.Quark]
text = "Quarks are subatomic particles that form |hadron|s."
`

Here, a connection is created from the node with ID `Quark` to the node with ID `Hadron`. See |AnchorSyntax| for the various ways you can link to other nodes from within the node text itself.

There are several different ways to connect nodes, including ones where you can add metadata to the connection itself. See |Connections| for more details.

## Where to go from here

- Dive deeper into the |syntax| used to write your graph
- Glimpse into en's future in the |roadmap|
- Visit the |data endpoints|/data| for a raw view of the graph
- See an index of all pages in the |tree|/tree|
- Look under the hood in the |source code|https://codeberg.org/jutty/en repo
"""

[nodes.Connections]
text = """
A connection is a link from one node to another. As shown in |GetStarted|, the simplest way to create them is by adding an |anchor|Syntax#Anchors| in the node text itself. However, there are other ways to create connections between nodes.

## Links

Even if a node is not mentioned in the node text, you can still add connections to it.

For simple connections without any associated properties, you can simply add links, which are lightweight connections without any metadata aside from the automatically determined source and destination:

`
[nodes.Quark]
text = "A subatomic particle that forms hadrons."

links = [ "Particle", "Hadron" ] `

This will create two outgoing connections from Quark: to Particle and to Hadron.

## Rich connections

For richer connections that have their own properties, you can use the full connection syntax:

`
[nodes.Earth.connections.Moon]
kind = "Satellite"

[nodes.Earth.connections.MilkyWay]
kind = "Galaxy"
`

This will create connections from the node with ID `Earth` to the nodes with ID `Moon` and `MilkyWay` and add the "Satellite" and "Galaxy" kinds to each connection, respectively. This will add a corresponding CSS class with the same name to the connection when it's rendered so you can style it in special ways and is also reflected in the |output formats|outputs.
"""

[nodes.Outputs]
text = """
en take as its input one or more graph files containing your node definitions. It then processes your graph, looks for connections and configuration values and produces one or more outputs depending on your settings:

- A browsable, live-served website (such as this one)
- A |TOML| representation of the graph that can be used as a basis to generate other, adapted graphs
- A JSON representation of the graph that can be further analyzed and interpreted with third-party tools

The output formats are not simply a translation of the input, but enrich them. Among other things, they transpile en's |markup syntax|Syntax into HTML, add metrics about how nodes are connected and flag which missing nodes are most sought after by dangling connections.
"""

[nodes.SourceBuild]
text = """
An overview on building from source is available in the |Get Started|GetStarted#Build page. This page contains a more detailed and considered approach for those interested.

en is developed on NixOS and builds are tested on both Debian and Alpine, meaning en should compile and run on both glibc and musl systems.

## Dependencies

A Rust toolchain is required to build en itself and can be installed through |rustup|https://rustup.rs/|.

For compiling the en dependencies, you will also need a C toolchain: a compiler and a libc (e.g. `gcc` + `glibc` or `clang` + `musl`), which may already be installed on your system.

For the two tested systems, all you need are the following packages:

%
    Distribution   ! Needed packages
    *Debian*       | `gcc` `libc6-dev`
    *Alpine*       | `clang`
%

You may also need `curl`, `git` and `ca-certificates` depending on how you will fetch the source code.

## Building from a Git clone

Aside from the `cargo install` approach described in |GetStarted|GetStarted#Build, you can alternatively fetch the code yourself using Git, which allows you to inspect and change it before compiling:

`
git clone -b v{{ en_version }} --single-branch https://codeberg.org/jutty/en
cd en
cargo build --locked --release
`

In this case, the `en` binary will be in `target/release/en`.

## Runnable examples

You can find the exact commands used to test installation on both systems in the |<code>containers</code>|https://codeberg.org/jutty/en/src/branch/main/containers| directory of the en source repository.

"""

[nodes.Node]
text = """
A node is defined in your graph file starting with a table header of the form:

`
[nodes.ID]
`

Where `ID` is an identifier of your choice.

While the |TOML| specification is quite flexible regarding what characters can make up this identifier, it's recommended that you keep it simple. Non-English characters are fine, but characters with special meaning in |en syntax|Syntax and URL parsing might lead to unexpected results. See |AnchorSyntax| for details.

## Fields

Nodes can have several optional fields that alter how en interprets and displays them.

- `title`: The main heading shown at the top of the page and tab title
- `text`: The textual content that is shown when the node is accessed
- `redirect`: Where to redirect any attempt to access the node
- `links`: An array of identifiers for other nodes to which this node is connected
- `listed`: Whether this node should be listed in the index and tree pages. This won't prevent the node from being found or linked to directly through its ID

## Example

`
[nodes.Citrus]
title = "Citrus Trees"
listed = true
text = "Citrus is a |genus| of trees known mainly for its fruits."
redirect = "Citric"
links = [ "Orange", "Lemon", "Lime", "Grapefruit", ]

[[nodes.Citrus.connections]]
from = "Citrus"
to = "Citric acid"
`

### Default values

The example above has all fields in it for completeness, but all fields have default values and are therefore optional. This means that explicitly writing `listed = true` is the same as not setting it at all.

The default values for unset fields are:

- `title`: Same as the identifier
- `text`: An empty string (i.e. `text = ""`)
- `redirect`: An empty string
- `links`: An empty array (i.e. `links = []`)
- `listed`: `true`
"""

[nodes.CLI]
title = "CLI Options"
text = """
You can set the hostname, port and graph file path using CLI options:

`
en --hostname 10.0.1.2 -p 443 --graph ./graphs/my-graph.toml
`

## Options

### Graph

The relative or absolute path to the graph definition |TOML| file.

*Variants:* `--graph`, `-g`

*Default:* `./static/graph.toml`

*Examples:*

`
en -g graph.toml
en --g ./static/my-graph.toml
`

### Hostname

The IP address where the en server will be accessible.

*Variants:* `--hostname`, `-h`

*Default:* `0.0.0.0`

*Examples:*

`
en -h localhost
en --hostname 10.120.0.5
`

### Port

The port where the en server will be accessible.

*Variants:* `--port`, `-p`

*Default:* A random available port assigned by the operating system

*Examples:*

`
en -p 3003
en --port 3000
`

## Using multiple options

You can combine these options as you wish:

`
en -h localhost -p 3000
en -p 3003 --host localhost --graph ./graph.toml
en --g ./graph.toml -p 1312
`

If an option is specified more than once, the last use will override any previous ones.
"""

[nodes.Syntax]
text= """
Some fields of your en graph, namely the |Node| text field, have support for special syntax that allows you to apply formatting and create connections between your graph's nodes.

If you are familiar with Markdown|https://en.wikipedia.org/wiki/Markdown|, you'll find some features familiar, with some notable differences too.

## Anchors

Anchors are the most important and powerful syntactic element you will work with because they can create connections between nodes when you use them. They have the following basic syntax:

`
anchor|destination
`

For example:

`
particles|ParticlePhysics
`

This example will render as the word "particles" pointing to a node with ID `ParticlePhysics` because the destination is not an external URL.

When both sides are the same, you can simply write:

`
|ParticlePhysics|
`

An external anchor looks like this:

`
docs|https://en.jutty.dev/node/Documentation
`

External anchors are identified by the presence of either a `:` or a `/` character in the destination. This works for special handlers, such as `mailto:user@domain.com`, and destinations relative to the website root like `/about`.

If the left side contains spaces, you need a leading `|` character:

`
|en docs|https://en.jutty.dev/node/Documentation
`

To make a plain address an anchor, wrap it in two `|` characters:

`
|https://en.jutty.dev|
`

### Node anchors

Because anchors between nodes are central to en, there is special syntax to make them as fluid as possible to create without cluttering the text too much.

en can resolve IDs case insensitively (with priority to case-sensitive matches),  will ignore trailing punctuation and a single `s` character for plurals, and will also collapse spaces when trying to resolve an ID, so you can also write:

`
check out the en |documentation|, or look at the |example|s.
`

If there is a node with id Documentation and another with id Example, they'd be linked to by the linked anchors.

While flexible, this can sometimes be ambiguous. See |AnchorSyntax| for more details and caveats regarding anchors.

## Formatting

Supported formatting syntax includes:

- `*` for bold
- `_` for italics
- `__` for underline
- `~~` for strikethrough

To apply these, you can wrap a word in the formatting operators, so for instance `*this*` will be rendered as *this* and `~~this~~` as ~~this~~.

## Checkboxes

You can use `[ ]` and `[x]`  to render checkboxes:

`
- [ ] not done
- [x] done
`

- [ ] not done
- [x] done

## Blocks

A block is any group of lines separated by empty lines:

`
block A
still block A
block A's last line

block B starts here
block B ends here

this is block C
`

By default, a block not starting with any special syntax is a paragraph, such as this very line you are reading.

Some blocks will join the lines together, meaning even if you write:

`
a
b
c
`

You still get "a b c" as a result. This is the case for paragraphs, but not for lists, verse blocks, tables and preformatted text. Blockquotes support both modes.

This is useful when editing your text, allowing you to break some thoughts and special syntax without losing control over where your paragraph ends, particularly when handling huge paragraphs.

If you want to force lines to break, you can use a `<` character at the end of a line:

`
a <
b <
c <
`

Which renders as:

a <
b <
c <

While useful to break a few lines on demand, if you have a large block of lines you want to break this can become cumbersome. That's where verse blocks are useful.

### Verse

Verse blocks are delimited by a `&` character at their first and last line and are useful to avoid precisely this line-joining behavior of paragraphs. They will break all lines without need for a trailing `<` character:

`
&
    these lines
    break just fine
    once they are over
&
`

&
    these lines
    break just fine
    once they are over
&

### Quotes

A block of lines starting with a `>` character will render as a quote:

`
> Who'll change old lamps for new ones?
`

> Who'll change old lamps for new ones?

Quote blocks have two forms. If you prepend all blocks with a `>`, line breaks will be preserved, not collapsing the whole quote into a single line:

`
> When I was alive
> I was dust which was,
> But now I am dust in dust
> I am dust which never was.
`

> When I was alive
> I was dust which was,
> But now I am dust in dust
> I am dust which never was.

If you would like the quote to be collapsed into a single line instead, you can leave just the first `>` and continue until the next empty line:

`
> And should I feel kindness towards my enemies?
No: from that moment I declared everlasting war against the species,
and more than all, against him who had formed me
and sent me forth to this insupportable misery.
`

> And should I feel kindness towards my enemies?
No: from that moment I declared everlasting war against the species,
and more than all, against him who had formed me
and sent me forth to this insupportable misery.

You can still use `<` characters to force line breaks in this case.

#### Citation

To add a citation to your quote block, start a line with two `-` characters:

`
> i sat down next to her
> with a large frosty _bandito_
> she gazed at the ghost of me
> asked _“amigo, como esta”_
-- Assotto Saint, Lady & Me
`

> i sat down next to her
> with a large frosty _bandito_
> she gazed at the ghost of me
> asked _“amigo, como esta”_
-- Assotto Saint, Lady & Me

If you have a more complex citation, you can use multiple lines starting with `--`. All such lines will be joined together in the citation. If you need to break lines, use the `<` character at the end of a line:

`
> Dois grandes mitos dominam a história oficial do Brasil:
  o mito da índole pacífica do brasileiro e o da "democracia racial".
-- Benedita da Silva,
-- |Speech on the Federal Senate|https://www25.senado.leg.br/web/atividade/pronunciamentos/-/p/pronunciamento/165765|,
-- March 3rd, 1995 <
-- International Day for the Elimination of Racial Discrimination
`

> Dois grandes mitos dominam a história oficial do Brasil:
  o mito da índole pacífica do brasileiro e o da "democracia racial".
-- Benedita da Silva,
-- |Speech on the Federal Senate|https://www25.senado.leg.br/web/atividade/pronunciamentos/-/p/pronunciamento/165765|,
-- March 3rd, 1995 <
-- International Day for the Elimination of Racial Discrimination

The first URL found in your citation will be used as the blockquote element's `cite` value.

### Lists

A block of lines starting with a `-` character will be rendered as an unordered list:

`
- cyan
- amber
- crimson
`

- cyan
- amber
- crimson

Lines starting with a `+` character will create numbered lists instead:

`
+ ichi
+ ni
+ san
`

+ ichi
+ ni
+ san

In both kinds of lists, you can use an uniform amount of indentation to nest the items:

`
- purple
    - red
    - blue
- orange
    - red
    - yellow
        - red
        - green
`

- purple
    - red
    - blue
- orange
    - red
    - yellow
        - red
        - green

### Tables

Tables are blocks delimited by a sole `%` on its own line:

`
%
    Country    !  Capital
    Colombia   |  Bogotá
    Belgium    |  Brussels
    Palestine  |  Jerusalem
    Zambia     |  Lusaka
%
`

%
    Country   !  Capital
    Colombia  |  Bogotá
    Belgium   |  Brussels
    Palestine |  Jerusalem
    Zambia    |  Lusaka
%

Table cells are delimited by either a `!` for headers or `|` for common cells. These delimiters must be surrounded by at least one space to each side and are optional at the first and last position of each line.

This means you can use any of the following formats:

`
%
      middle |  only
       tail  |  only   |
    |  lead  |  only
    | fully  | wrapped |
%
`

%
      middle | only
      tail   | only |
    | lead   | only
    | fully  | wrapped |
%

Because at least one space is required around each delimiter, you must indent the table inside the surrounding `%` markers by at least one space.

## Rendering unformatted text

The backtick character `\\`` can be used to render unformatted blocks and inline text:

`
The asterisk `*` is special in en markup syntax.
`

> The asterisk `*` is special in en markup syntax.

Using the syntax above, the asterisk won't be interpreted as the start of bold formatting and instead will be shown like this: `*`.

This is useful for code but also for rendering characters with special meaning you wish to mention literally.

Backticks on their own line will start and close a block of unformatted text such as the ones being used throughout this documentation to show code:

`
\\`
everything in here will be rendered without formatting
\\`
`

Finally, you can precede any character with a `\\\\` to fully _escape_ that character from being interpreted. Because |TOML| also treats backslashes specially, you'll likely need to use double slashes, as in `\\\\\\\\`, unless you wrap your TOML strings in single quotes. See |Escaping| for more details and examples.

## Raw HTML

If you need some more advanced feature that is not supported directly by en's markup syntax, you can always just write plain HTML and it will be passed along. For example, you could render a form:

`
&lt;form style="text-align: center;"&gt;
    &lt;label for="name"&gt; *__Name__* &lt;/label&gt;
    &lt;input type="text" id="name"/&gt;
    &lt;input type="submit"/&gt;
&lt;/form&gt;
`

<form style="text-align: center;">
    <label for="name"> *__Name__* </label>
    <input type="text" id="name"/>
    <input type="submit"/>
</form>

Notice that, as shown in this example, you can mix en syntax and HTML. You might want to add a space between your HTML tags and en special syntax so the boundary is clearer, but otherwise they don't tend to overlap since the symbols most used in HTML are not special in en with the exception of `<`, which is interpreted specially only at the end of lines.

If you want to avoid either one of these syntaxes from being interpreted specially, you should escape the relevant characters as explained in the previous section.

## Known issues

- Nesting multiple different formatting symbols is currently supported only in a few cases. Better nesting is on the |roadmap|, but currently may not work as expected.
"""

[nodes.Escaping]
text = """
The backslash (`\\\\`) works by immediately adding the following character as a literal and skipping any further interpretation of it.

For example, if you want to write inline unformatted text containing a backtick, you will need to escape it, so that to render `println!("\\`")` as unformatted inline text, you'd write `\\`println!("\\\\\\`")\\``, otherwise the second backtick would close the code tag midway through it.

If you want to render a literal backslash, you can escape the backslash itself by using two backslashes: `\\\\\\\\`.

## Interactions with TOML escaping

Notice that |TOML| itself also handles escape codes, so to pass a backslash you will need to escape it as a double backslash inside strings delimited by double quotes or triple double quotes. You can use a single backslash inside a string delimited by single quotes:

`
[node.Double]
text = "You need double slashes here: \\\\\\\\*"

[node.TripleDouble]
text = \"""
And here: \\\\\\\\*
\"""

[node.Single]
text = 'Here you need just one: \\\\*"

[node.TripleSingle]
text = '''
Here too: \\\\*
'''
`

This has nothing to do with en's markup syntax _per se_, it's just a consequence of how backslashes are also special in TOML syntax. For more details, see the |TOML documentation on Strings|https://toml.io/en/v1.1.0#string|.

## Interactions with HTML

en will happily accept HTML code and pass it along to the browser, so you can use any feature from it as a sort of superset.

If you want to prevent a particular part of your text from being interpreted as HTML, you can escape it |as you normally would|https://developer.mozilla.org/en-US/docs/Glossary/Character_reference|.

The fact you are using HTML does not exclude en syntax from being interpreted, although this may change in the future. Presently, you need to escape en markup syntax if you want it printed literally even inside HTML tags. This matters because en |uses its syntax to create connections|AnchorSyntax| between your graph's nodes and makes several decisions based on these relations.
"""

[nodes.AnchorSyntax]
title = "Anchor Syntax"
text = """
en's anchor syntax can be very flexible, but some situations lead to ambiguity.

In short, following these two rules should keep you out of trouble:

- *Avoid characters with special meanings in your node IDs*: |TOML| allows you to use a wide range of characters in identifiers, but when writing your graph it's better keep your IDs free of some characters. Accents and ideograms are fine, but characters such as `#`, `&`, `:` and `/` are not because they are interpreted differently by en and URL parsers, which might lead to unexpected results
- *Know you can be explicit to force proper evaluation*: When needed, use full three-pipe anchors, as in `|text|destination|`, to make your anchors fully unambiguous

## Basic anchor
See the |Anchors section in the Syntax page|Syntax#Anchors| for the basic anchor syntax. The following sections go into more detail on some edge cases.

### Trailing characters in anchors

For internal anchors, most punctuation is automatically separated from the anchor destination so you can simply write:

`
This gem|PreciousStone, though green, was not an emerald.
`

> This gem|PreciousStone, though green, was not an emerald.

This is one of the reasons to avoid punctuation in your node IDs.

The punctuation symbols that are ignored at the trailing boundary of anchors are:

`
, . : ; ? ! ( ) ' " ` | _ * \\
`

For external anchors, you often must add a third `|` to explicitly set the end because external URLs can have all sorts of arbitrary characters. This is not necessary for spaces, but it is for other characters.

## Plural node anchors

Something similar applies to the lowercase letter `s`:

`
We found three |boat|s at the marina.
`

This conveniently lets you write plural words as anchors to their singular form without having to write:

`
We found three boats|Boat at the marina.
`

Which is annoying to write and makes the text a lot less fluid.

Unlike with punctuation, this doesn't mean you can't have a node with the ID `s`. You can, but you'll have to write your anchors to it always with a trailing pipe:

`
The |letter s|s| is important so we dedicated a whole page to it: |s|!
`

## Spaced node anchors

If you write a node anchor with spaces, it will be collapsed:

`
This |Node Anchor| will work as if it were |NodeAnchor|.
`

Accordingly, node IDs should not have spaces because, among other things, this feature makes it impossible to create an anchor to them.

## Case-insensitive fallbacks

Because node ID resolution redirects to a lowercase match if it can't find an exact match, you can write:

`
The next |precious stone| was stolen in 1973.
`

And the visible text will still display as "precious stone" but point to an ID such as `PreciousStone`.

This is not a problem if you want to refer to a specific ID that differs only in case because the case-sensitive match takes priority.

## URL detection

en must differentiate node anchors from outgoing URLs:

`
|internal|Internal|
|external|https://external.example.com|
`

It does this by looking at the destination and checking if it contains a `/` or `:`. That's one more reason to avoid these characters in your node IDs.
"""

[nodes.Graph]
text = """
A graph is a data structure composed of connected (and disconnected) nodes.

A familiar example is that of a social network. Each account can be thought of as a node and the "follow" and "follower" relationships can be thought of as edges (connections). A node may have many or few connections, and the nodes it is connected to are meaningful to understand how it fits into the whole.

en uses this concept to create a writing tool, allowing you to map out complex thoughts as a web of connected texts.
"""

[nodes.TOML]
text = """
TOML is a configuration format that can be easily read and understood by humans and machines alike.

It was chosen as en's main input format for its obvious semantics, because it's more readable, has friendlier strings compared to alternatives such as JSON and less convoluted indentation compared to YAML.

One of the most valued attributes in en's design is readability. TOML provides powerful multi-line strings that can trim whitespace and literal multiline string that avoid the need for escaping. This couples well with en's own |markup syntax|Syntax.

To learn more about TOML, you can visit its website at |https://toml.io|.

To see the TOML representation for the graph you are reading right now, visit the |data endpoints|/data|.
"""

[nodes.Acknowledgments]
text = """
en is only possible thanks to a number of projects and people:

## Programming

- |The Rust Programing Language|https://rust-lang.org/
- Tokio|https://tokio.rs/
- Axum|https://github.com/tokio-rs/axum
- Tera|https://keats.github.io/tera/
- Serde|https://serde.rs/ and the |toml crate|https://github.com/toml-rs/toml
- TOML|https://toml.io/en/

## Services & Utilities

- Git|https://git-scm.com/
- Codeberg|https://codeberg.org/
- Forgejo|https://forgejo.org/
- Just|https://just.systems/
- watchexec|https://github.com/watchexec/watchexec
- cargo-llvm-cov|https://github.com/taiki-e/cargo-llvm-cov

## Typography

- Reforma|https://pampatype.com/reforma|, by PampaType|https://pampatype.com under the Creative Commons ND 4.0 license
- Cormorant|https://github.com/CatharsisFonts/Cormorant|, by |Christian Thalmann|https://github.com/CatharsisFonts under the SIL Open Font License
- Rawengulk|https://www.glukfonts.pl/font.php?font=Rawengulk|, by |gluk Fonts|https://www.glukfonts.pl under the SIL Open Font License
- |Mononoki|https://madmalik.github.io/mononoki/|, by |Matthias Tellen|https://github.com/madmalik| under the SIL Open Font License
- Maven|https://github.com/m4rc1e/mavenproFont|, by |Joe Prince and Project Authors|https://github.com/m4rc1e/mavenproFont/blob/main/AUTHORS.txt under the SIL Open Font License

## Software

- |NixOS|https://nixos.org/|, |Debian|https://debian.org|, |Alpine|https://alpinelinux.org and their kernel|https://www.kernel.org/
- LibreWolf|https://librewolf.net/ and its upstream |Mozilla Firefox|https://www.firefox.com/
- InkScape|https://inkscape.org/
"""

[nodes.RedirectTest]
redirect = "Start"

[nodes.Roadmap]
text = """

## Upcoming

## `v0.5.0-alpha`
- [ ] Rich connections
- [ ] Docs for custom assets and templates
- [ ] Fix anchors containing `/` and `#` considered node IDs
- [x] Fix `PreFormat` blocks rendering HTML tags

<hr style="margin: 8em 0 2em;">

## Backlog
### Syntax
- [ ] Improve nested formatting
- [ ] Invert where redirects are set
- [ ] Special sections
    - Top-bound
        - [ ] Top-bound is not included in the summary (tooltip)
        - Sections
            - [ ] Definition (implies metadata `has_definition`)
            - [ ] See also (implies a kind of connection, e.g. `related`)
            - [ ] Not to be confused with (implies a kind of connection)
    - [ ] Contrast with (implies a kind of connection)
    - [ ] Example (implies metadata `has_example`)
    - Bottom-bound
        - [ ] References/influences (implies metadata `has_references`)
            - [ ] Aggregated from the full text content

### Metrics
- [ ] Most linked to nodes
- [ ] Most linked from nodes
- [ ] Most linked

### Rendering
- [ ] Sorting of tree, index list and drop-down navigation
    - [x] Alphabetic
    - [ ] By most linked to
    - [ ] By most linked
- Tree
    - [ ] Hide tree leaves from the top level
    - [ ] Branch deeper
- Customization
    - [ ] Custom assets (favicon, CSS)
        - [x] Drop all hardcoded assets endpoints
    - [ ] Custom header include
    - [x] Custom templates
        - [ ] user-supplied loading order (e.g. through filenames)
    - [ ] Themes
- [ ] Table of contents

### Connections
- [ ] `#` syntax for header ID anchors
- Connection kinds
    - [ ] Mutual
    - [ ] Category <-> Membership
    - [ ] Opposite <-> Equivalent
    - [ ] Contrast <-> Similar
    - [ ] Cognate <-> Unrelated
    - [ ] Specialization <-> Generalization
    - [ ] Custom connection kinds
    - [x] External anchors
- [ ] Suffix-aware anchors
    - [x] Plural anchors (`|node|s` -> `node`)
    - [x] Ignore trailing punctuation
    - [ ] Conjugation anchors (`|will|ed` -> `will`)
    - [ ] Configurable suffixes

### I/O formats

#### Input
- [ ] Frontmatter format
- [ ] Multi-file graphs
- [ ] Multi-graph

#### Output
- [ ] Add separate TOML endpoints for pre/postprocessed
- [ ] Render to filesystem
- [ ] Single-page rendering
- [ ] Consider printing parsing errors to console by default

### Templating
- [ ] Simplify template code with includes, macros and custom functions
- [ ] Move compiled templates to a static ref
    - See: |https://keats.github.io/tera/docs/#:~:text=only%20happen%20once|
- [ ] Reduce whitespace
    - See: |https://keats.github.io/tera/docs/#whitespace-control|

### Server
- [ ] Full-text search

### Documentation
- [ ] Generate `meta.config` docs from JSON schema

#### Validation
- [ ] Finalize JSON schema
- [ ] Add CI step with `taplo lint`

### Code
- [ ] Assess `Option` return types that should be `Result`

### Performance
- [ ] Caching
- [ ] Reduce O(n) calls in the formats module

### Done
<details>
<summary>Toggle to expand</summary>

#### Syntax
- Formatting
    - [x] Blockquotes
    - [x] Tables
    - [x] Nested formatting
    - [x] Headers
    - [x] Preformatted blocks
    - [x] _Oblique_,
    - [x] __Underline__
    - [x] ~~Strikethrough~~
    - [x] *Bold*
    - [x] `Inline code`
    - [x] Lists
        - [x] Nested lists
    - [x] Checkboxes
        - [x] Move this roadmap to en

#### Connections
- [x] Count connection to a redirect as a connection to the target
- [x] Spaced node anchor (`|red fox|` -> `redfox` -> `RedFox`)
- [x] Automatic connections from anchors

#### I/O formats
##### Input
- [x] Array syntax for lightweight connections

##### Output
- [x] Make error output more clean when `DEBUG` is unset

##### Metrics
- [x] Detached edges

#### Rendering
- [x] Render detached anchors differently
- [x] Strip/render some syntax in Tree text preview
- [x] Drop-down navigation

#### Server
- [x] Redirects
- [x] Automatic IDs
- [x] Automatic titles
- [x] Mismatch between TOML ID and provided ID

#### Performance
- [x] Move more logic from Serial to Graph submodules
- [x] Further centralize state

</details>
"""

[meta.config]
content_language = "en"
footer_credits = false
error_poem = true
node_selector = true
navbar_search = true
about = true
footer_text = """
acknowledgments|Acknowledgments &bullet; |source code|https://codeberg.org/jutty/en
"""