\nEager to jump right in? Head straight to GetStarted.\n
\n\nen is a writing tool. It was designed for complex, conceptually heavy projects, where the relationships between terms matter and possibly have their own attributes. This very website is running en. 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.
\n\nIt 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. en also features its own markup language that was designed to be readable and as unobstructive as possible to the flow of writing.
\n\nThese 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.
\n\nen was created out of the desire to write a book that did not follow a linear progression. But it can be used for note-taking, studying, documentation, encyclopedic content and any other format that benefits from a focus on the connections between pages. It aims to remove the constraints imposed by trying to mimic the linearity of typical nonfiction writing.
\n\nIt'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.
\n\nBecause 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.
\n\nen is in its infancy. Right now, most of the work is focused on making the markup language more robust. Some interesting planned features include:
\n\n\n.en files with TOML frontmatterIf you like what you see and are curious about en's future, take a look at the roadmap for a more comprehensive view of what else is to come.
\n\nSee the Get Started page to learn how to install and use en.
","summary":"\n\nEager to jump right in? Head straight to GetStarted.","title":"Introduction","links":[],"redirect":"","listed":true,"connections":{"TOML":{"to":"TOML","from":"Introduction","detached":false},"GetStarted":{"to":"GetStarted","from":"Introduction","detached":false},"Graph":{"to":"Graph","from":"Introduction","detached":false},"Roadmap":{"to":"Roadmap","from":"Introduction","detached":false},"Syntax":{"to":"Syntax","from":"Introduction","detached":false}},"stats":{"outgoing":0,"incoming":0}},"TOML":{"id":"TOML","text":"TOML is a configuration format that can be easily read and understood by humans and machines alike.
\n\nIt 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.
\n\nOne 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.
\n\nTo learn more about TOML, you can visit its website at https://toml.io.
\n\nTo see the TOML representation for the graph you are reading right now, visit the data endpoints.
","summary":"TOML is a configuration format that can be easily read and understood by humans and machines alike.","title":"TOML","links":[],"redirect":"","listed":true,"connections":{"Syntax":{"to":"Syntax","from":"TOML","detached":false}},"stats":{"outgoing":0,"incoming":0}},"CLI":{"id":"CLI","text":"You can set the hostname, port and graph file path using CLI options:
\n\n\nen --hostname 10.0.1.2 -p 443 --graph ./graphs/my-graph.toml\n\n\n
The relative or absolute path to the graph definition TOML file.
\n\nVariants: --graph, -g
Default: ./static/graph.toml
Examples:
\n\n\nen -g graph.toml\nen --g ./static/my-graph.toml\n\n\n
The IP address where the en server will be accessible.
\n\nVariants: --hostname, -h
Default: 0.0.0.0
Examples:
\n\n\nen -h localhost\nen --hostname 10.120.0.5\n\n\n
The port where the en server will be accessible.
\n\nVariants: --port, -p
Default: A random available port assigned by the operating system
\n\nExamples:
\n\n\nen -p 3003\nen --port 3000\n\n\n
You can combine these options as you wish:
\n\n\nen -h localhost -p 3000\nen -p 3003 --host localhost --graph ./graph.toml\nen --g ./graph.toml -p 1312\n\n\n
If an option is specified more than once, the last use will override any previous ones.
","summary":"You can set the hostname, port and graph file path using CLI options:","title":"CLI Options","links":[],"redirect":"","listed":true,"connections":{"TOML":{"to":"TOML","from":"CLI","detached":false}},"stats":{"outgoing":0,"incoming":0}},"Acknowledgments":{"id":"Acknowledgments","text":"en is only possible thanks to a number of projects and people:
\n\nSome 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.
\n\nIf you are familiar with Markdown, you'll find some features familiar, with some notable differences too.
\n\nAnchors 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:
\n\n\nanchor|destination\n\n\n
For example:
\n\n\nparticles|ParticlePhysics\n\n\n
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:
\n\n\n|ParticlePhysics|\n\n\n
An external anchor looks like this:
\n\n\ndocs|https://en.jutty.dev/node/Documentation\n\n\n
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:
\n|en docs|https://en.jutty.dev/node/Documentation\n\n\n
To make a plain address an anchor, wrap it in two | characters:
\n|https://en.jutty.dev|\n\n\n
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.
\n\nen 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:
\ncheck out the en |documentation|, or look at the |example|s.\n\n\n
If there is a node with id Documentation and another with id Example, they'd be linked to by the linked anchors.
\n\nWhile flexible, this can sometimes be ambiguous. See AnchorSyntax for more details and caveats regarding anchors.
\n\nSupported formatting syntax includes:
\n\n\n* for bold_ for italics__ for underline~~ for strikethroughTo apply these, you can wrap a word in the formatting operators, so for instance *this* will be rendered as this and ~~this~~ as this.
You can use [ ] and [x] to render checkboxes:
\n- [ ] not done\n- [x] done\n\n\n\n
A block is any group of lines separated by empty lines:
\n\n\nblock A\nstill block A\nblock A's last line\n\nblock B starts here\nblock B ends here\n\nthis is block C\n\n\n
By default, a block not starting with any special syntax is a paragraph, such as this very line you are reading.
\n\nSome blocks will join the lines together, meaning even if you write:
\n\n\na\nb\nc\n\n\n
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.
\n\nThis 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.
\n\nIf you want to force lines to break, you can use a < character at the end of a line:
\na <\nb <\nc <\n\n\n
Which renders as:
\n\na
\nb
\nc
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.
\n\nVerse 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:
\n&\n these lines\n break just fine\n once they are over\n&\n\n\n
these lines
break just fine
once they are over\n
A block of lines starting with a > character will render as a quote:
\n> Who'll change old lamps for new ones?\n\n\n\n
\nWho'll change old lamps for new ones?\n\n\n
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:
\n> When I was alive\n> I was dust which was,\n> But now I am dust in dust\n> I am dust which never was.\n\n\n\n
\nWhen I was alive\n\n
\n I was dust which was,
\n But now I am dust in dust
\n I am dust which never was.\n
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:
\n> And should I feel kindness towards my enemies?\nNo: from that moment I declared everlasting war against the species,\nand more than all, against him who had formed me\nand sent me forth to this insupportable misery.\n\n\n\n
\nAnd should I feel kindness towards my enemies?\nNo: from that moment I declared everlasting war against the species,\nand more than all, against him who had formed me\nand sent me forth to this insupportable misery.\n\n\n
You can still use < characters to force line breaks in this case.
To add a citation to your quote block, start a line with two - characters:
\n> i sat down next to her\n> with a large frosty _bandito_\n> she gazed at the ghost of me\n> asked _“amigo, como esta”_\n-- Assotto Saint, Lady & Me\n\n\n\n
\ni sat down next to her\n\n
\n with a large frosty bandito
\n she gazed at the ghost of me
\n asked “amigo, como esta”
Assotto Saint, Lady & Me\n
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:
\n> Dois grandes mitos dominam a história oficial do Brasil:\n o mito da índole pacífica do brasileiro e o da \"democracia racial\".\n-- Benedita da Silva,\n-- |Speech on the Federal Senate|https://www25.senado.leg.br/web/atividade/pronunciamentos/-/p/pronunciamento/165765|,\n-- March 3rd, 1995 <\n-- International Day for the Elimination of Racial Discrimination\n\n\n\n
\nDois grandes mitos dominam a história oficial do Brasil:\n o mito da índole pacífica do brasileiro e o da \"democracia racial\".\n\n\n\n
Benedita da Silva,\n Speech on the Federal Senate,\n March 3rd, 1995
\n International Day for the Elimination of Racial Discrimination\n
The first URL found in your citation will be used as the blockquote element's cite value.
A block of lines starting with a - character will be rendered as an unordered list:
\n- cyan\n- amber\n- crimson\n\n\n\n
Lines starting with a + character will create numbered lists instead:
\n+ ichi\n+ ni\n+ san\n\n\n\n
In both kinds of lists, you can use an uniform amount of indentation to nest the items:
\n\n\n- purple\n - red\n - blue\n- orange\n - red\n - yellow\n - red\n - green\n\n\n\n
Tables are blocks delimited by a sole % on its own line:
\n%\n Country ! Capital\n Colombia | Bogotá\n Belgium | Brussels\n Palestine | Jerusalem\n Zambia | Lusaka\n%\n\n\n\n
| Country | \nCapital | \n
|---|---|
| Colombia | \nBogotá | \n
| Belgium | \nBrussels | \n
| Palestine | \nJerusalem | \n
| Zambia | \nLusaka | \n
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:
\n\n\n%\n middle | only\n tail | only |\n | lead | only\n | fully | wrapped |\n%\n\n\n\n
| middle | \nonly | \n
| tail | \nonly | \n
| lead | \nonly | \n
| fully | \nwrapped | \n
Because at least one space is required around each delimiter, you must indent the table inside the surrounding % markers by at least one space.
The backtick character ` can be used to render unformatted blocks and inline text:
\nThe asterisk `*` is special in en markup syntax.\n\n\n\n
\nThe asterisk * is special in en markup syntax.\n\n\nUsing 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.
\n\nBackticks 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:
\n\n\n`\neverything in here will be rendered without formatting\n`\n\n\n
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.
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:
\n\n\n<form style=\"text-align: center;\">\n <label for=\"name\"> *__Name__* </label>\n <input type=\"text\" id=\"name\"/>\n <input type=\"submit\"/>\n</form>\n\n\n\n\n
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.
\n\nThe easiest way to get started is by downloading a pre-built binary.
\n\nx64 Linux binaries are available from the git.jutty.dev package registry:
\n\n\n| Platform | \nDownload | \n
|---|---|
| x64 Linux GNU | \nen-x64-linux-gnu | \n
| x64 Linux musl | \nen-x64-linux-musl | \n
| x64 Windows MSVC | \nen-x64-windows-msvc | \n
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.
\n\nWindows builds are best-effort, cross-compiled, mostly tested only through Wine and not tested on CI.
\n\nOther platforms may be supported in the future depending on CI resources.
\n\nIf you are on another platform or simply prefer starting from source, you can also build en yourself.
\n\nYou will need:
\n\n\ngcc)Given the above is satisfied, you can build directly through Cargo:
\n\n\ncargo install --git https://codeberg.org/jutty/en --tag v0.4.0-alpha\n\n\n
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 v0.4.0-alpha part if you'd like to build the most recent development sources.
For more details on building from source, see SourceBuild.
\n\nOnce you have installed en, run it and point it to your graph:
\n\n\nen --graph my-graph.toml\n\n\n
See CLI for defaults and details on the available options.
\n\nThe graph is a TOML file. You can create nodes by adding text such as:
\n\n\n[nodes.Computer]\ntext = \"A computer is a machine capable of executing arbitrary instructions.\"\n\n\n
If you need longer text, it's more convenient to use triple quotes:
\n\n\n[nodes.Computer]\ntext = \"\"\"\nA computer is a machine capable of executing arbitrary instructions.\n\nThe main electronic component of a computer is its |motherboard|.\n\"\"\"\n\n\n
In the future, 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.
\n\nA node can have several other attributes. See Node for details on all of them.
\n\nNodes can have connections between each other. Each node page lists its outgoing and incoming connections.
\n\nThe simplest kind of connection is achieved by creating an anchor to another node in the node text itself:
\n\n\n[nodes.Quark]\ntext = \"Quarks are subatomic particles that form |hadron|s.\"\n\n\n
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.
\n\nThe 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: \\\\.
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:
\n\n\n[node.Double]\ntext = \"You need double slashes here: \\\\*\"\n\n[node.TripleDouble]\ntext = \"\"\"\nAnd here: \\\\*\n\"\"\"\n\n[node.Single]\ntext = 'Here you need just one: \\*\"\n\n[node.TripleSingle]\ntext = '''\nHere too: \\*\n'''\n\n\n
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.
\n\nen 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.
\n\nIf you want to prevent a particular part of your text from being interpreted as HTML, you can escape it as you normally would.
\n\nThe 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 between your graph's nodes and makes several decisions based on these relations.
","summary":"The backslash (\\) works by immediately adding the following character as a literal and skipping any further interpretation of it.","title":"Escaping","links":[],"redirect":"","listed":true,"connections":{"TOML":{"to":"TOML","from":"Escaping","detached":false},"AnchorSyntax":{"to":"AnchorSyntax","from":"Escaping","detached":false}},"stats":{"outgoing":0,"incoming":0}},"Roadmap":{"id":"Roadmap","text":"\n/ and # considered node IDsPreFormat blocks rendering HTML tagsSee Changelog for previously released versions.
\n\nThese changes are planned, but have not been assigned to an upcoming release yet.
\n\nhas_definition)related)has_example)has_references)# syntax for header ID anchors|node|s -> node)|will|ed -> will)meta.config docs from JSON schemataplo lintOption return types that should be ResultToggle to expand
Inline code|red fox| -> redfox -> RedFox)DEBUG is unset./templates and ./static/publicA node is defined in your graph file starting with a table header of the form:
\n\n\n[nodes.ID]\n\n\n
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 and URL parsing might lead to unexpected results. See AnchorSyntax for details.
\n\nNodes can have several optional fields that alter how en interprets and displays them.
\n\n\ntitle: The main heading shown at the top of the page and tab titletext: The textual content that is shown when the node is accessedredirect: Where to redirect any attempt to access the nodelinks: An array of identifiers for other nodes to which this node is connectedlisted: 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\n[nodes.Citrus]\ntitle = \"Citrus Trees\"\nlisted = true\ntext = \"Citrus is a |genus| of trees known mainly for its fruits.\"\nredirect = \"Citric\"\nlinks = [ \"Orange\", \"Lemon\", \"Lime\", \"Grapefruit\", ]\n\n[[nodes.Citrus.connections]]\nfrom = \"Citrus\"\nto = \"Citric acid\"\n\n\n
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:
\n\n\ntitle: Same as the identifiertext: An empty string (i.e. text = \"\")redirect: An empty stringlinks: An empty array (i.e. links = [])listed: trueAn overview on building from source is available in the Get Started page. This page contains a more detailed and considered approach for those interested.
\n\nen 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.
\n\nA Rust toolchain is required to build en itself and can be installed through rustup.
\n\nFor 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:
\n\n\n| Distribution | \nNeeded packages | \n
|---|---|
| Debian | \ngcc libc6-dev | \n
| Alpine | \nclang | \n
You may also need curl, git and ca-certificates depending on how you will fetch the source code.
Aside from the cargo install approach described in GetStarted, you can alternatively fetch the code yourself using Git, which allows you to inspect and change it before compiling:
\ngit clone -b v0.4.0-alpha --single-branch https://codeberg.org/jutty/en\ncd en\ncargo build --locked --release\n\n\n
In this case, the en binary will be in target/release/en.
You can find the exact commands used to test installation on both systems in the containers directory of the en source repository.
en's anchor syntax can be very flexible, but some situations lead to ambiguity.
\n\nIn short, following these two rules should keep you out of trouble:
\n\n\n#, &, : and / are not because they are interpreted differently by en and URL parsers, which might lead to unexpected results|text|destination|, to make your anchors fully unambiguousSee the Anchors section in the Syntax page for the basic anchor syntax. The following sections go into more detail on some edge cases.
\n\nFor internal anchors, most punctuation is automatically separated from the anchor destination so you can simply write:
\n\n\nThis gem|PreciousStone, though green, was not an emerald.\n\n\n\n
\nThis gem, though green, was not an emerald.\n\n\n
This is one of the reasons to avoid punctuation in your node IDs.
\n\nThe punctuation symbols that are ignored at the trailing boundary of anchors are:
\n\n\n, . : ; ? ! ( ) ' \" ` | _ * \n\n\n
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.
Something similar applies to the lowercase letter s:
\nWe found three |boat|s at the marina.\n\n\n
This conveniently lets you write plural words as anchors to their singular form without having to write:
\n\n\nWe found three boats|Boat at the marina.\n\n\n
Which is annoying to write and makes the text a lot less fluid.
\n\nUnlike 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:
\nThe |letter s|s| is important so we dedicated a whole page to it: |s|!\n\n\n
If you write a node anchor with spaces, it will be collapsed:
\n\n\nThis |Node Anchor| will work as if it were |NodeAnchor|.\n\n\n
Accordingly, node IDs should not have spaces because, among other things, this feature makes it impossible to create an anchor to them.
\n\nBecause node ID resolution redirects to a lowercase match if it can't find an exact match, you can write:
\n\n\nThe next |precious stone| was stolen in 1973.\n\n\n
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.
\n\nen must differentiate node anchors from outgoing URLs:
\n\n\n|internal|Internal|\n|external|https://external.example.com|\n\n\n
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.
A graph is a data structure composed of connected (and disconnected) nodes.
\n\nA 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.
\n\nen uses this concept to create a writing tool, allowing you to map out complex thoughts as a web of connected texts.
","summary":"A graph is a data structure composed of connected (and disconnected) nodes.","title":"Graph","links":[],"redirect":"","listed":true,"connections":{},"stats":{"outgoing":0,"incoming":0}},"Outputs":{"id":"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:
\n\n\nThe output formats are not simply a translation of the input, but enrich them. Among other things, they translate en's markup syntax into HTML, add metrics about how nodes are connected and flag which missing nodes are most sought after by dangling connections.
","summary":"en take as its input one or more graph files containing your node definitions.","title":"Outputs","links":[],"redirect":"","listed":true,"connections":{"Syntax":{"to":"Syntax","from":"Outputs","detached":false},"TOML":{"to":"TOML","from":"Outputs","detached":false}},"stats":{"outgoing":0,"incoming":0}},"Connections":{"id":"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 in the node text itself. However, there are other ways to create connections between nodes.
\n\nEven if a node is not mentioned in the node text, you can still add connections to it.
\n\nFor 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:
\n\n\n[nodes.Quark]\ntext = \"A subatomic particle that forms hadrons.\"\n\nlinks = [ \"Particle\", \"Hadron\" ]\n\n
This will create two outgoing connections from Quark: to Particle and to Hadron.
\n\nFor richer connections that have their own properties, you can use the full connection syntax:
\n\n\n[nodes.Earth.connections.Moon]\nkind = \"Satellite\"\n\n[nodes.Earth.connections.MilkyWay]\nkind = \"Galaxy\"\n\n\n
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.
You can customize several aspects of en by overriding its default templates, styles and other assets.
\n\npublic directoryThe static/public directory is searched by en in the current working directory and can also be passed as a command line option. All files placed inside this directory will be served by the en server as static files. You can create directories and organize files as you see fit, and then reference them through custom templates and includes.
If you place a file in a default path, it will override the default. Namely:
\n\n\nstatic/public/assets/favicon.svg: Website icon as seen on tabs and other UI elementsstatic/public/assets/style.css: Main CSS stylesheetstatic/public/assets/fonts/fonts.css: Fonts CSS index mapping the default families sans, serifed, mono, prose and title. The prose family is used for paragraphs such as in the node text content, while the sans family is used for UI elements such as the navigation bar and footer.The en server supports a variety of file types including plain text; data formats such as CSV, TOML and JSON; various font and image formats; and document formats such as PDF and EPUB. If you want to serve a file with a mimetype that is not included among the builtin ones, you can use the mimes configuration option. If you don't, the file will be served with mimetype application/octet-stream, which may or may not work depending on what you are actually serving and how it's being consumed.
You can override the default CSS and fonts using custom CSS files.
\n\nTo completely override the default style, you can place your replacement at the default path as explained in the previous section.
\n\nIf you just want to add small customizations, this can be better accomplished by adding a CSS file as part of a custom headers include, as explained in the next section.
\n\nen uses the Tera templating engine, which provides several features for creating your own templates.
\n\nWhen starting up, en will look for a templates directory in the current working directory. For each template, it looks up the corresponding filename inside this directory. If it can't find one, it will fallback to a default template.
For a list of templates along with their names, see the templates directory in the source code repository.
\n\nSee the Tera documentation for a more extensive description of the available features for writing templates.
\n\nOverriding an entire template can be very verbose, considering the default templates attempt to handle various edge cases.
\n\nTo make it easier to override the most common use cases, the following templates are consumed as \"includes\" in specific parts of the main templates if placed inside the templates directory with the suffix .include.html:
header: Included at the end of the default templates' base headerpost-body: Included after the body in the default base templatefavicon: Replaces the default favicon codestyles: Replaces the default CSS linksfooter: Replaces the footernavigation: Replaces the navigation barindex-header: Replaces the block showing the title and subtitle of the website in the index pageindex-list: Replaces the block showing the list of nodes in the index pageFor example, to override the block in the header of all pages that globally sets the CSS stylesheets, you can drop a file at templates/styles.include.html containing something like:
\n<link href=\"https://cdn.example.com/external.css\" rel=\"stylesheet\">\n<link href=\"/static/assets/my-styles.css\" rel=\"stylesheet\">\n\n","summary":"You can customize several aspects of en by overriding its default templates, styles and other assets.","title":"Customization","links":[],"redirect":"","listed":true,"connections":{"CLI":{"to":"CLI","from":"Customization","detached":false},"Configuration#mimes":{"to":"Configuration#mimes","from":"Customization","detached":true}},"stats":{"outgoing":0,"incoming":0}}},"root_node":"Introduction","incoming":{"Outputs":[{"to":"Outputs","from":"Connections","detached":false}],"Configuration#mimes":[{"to":"Configuration#mimes","from":"Customization","detached":true}],"AnchorSyntax":[{"to":"AnchorSyntax","from":"Syntax","detached":false},{"to":"AnchorSyntax","from":"GetStarted","detached":false},{"to":"AnchorSyntax","from":"Escaping","detached":false},{"to":"AnchorSyntax","from":"Node","detached":false}],"SourceBuild":[{"to":"SourceBuild","from":"GetStarted","detached":false}],"Escaping":[{"to":"Escaping","from":"Syntax","detached":false}],"PreciousStone":[{"to":"PreciousStone","from":"AnchorSyntax","detached":true}],"Graph":[{"to":"Graph","from":"Introduction","detached":false}],"TOML":[{"to":"TOML","from":"Introduction","detached":false},{"to":"TOML","from":"CLI","detached":false},{"to":"TOML","from":"Syntax","detached":false},{"to":"TOML","from":"GetStarted","detached":false},{"to":"TOML","from":"Escaping","detached":false},{"to":"TOML","from":"Node","detached":false},{"to":"TOML","from":"AnchorSyntax","detached":false},{"to":"TOML","from":"Outputs","detached":false}],"Node":[{"to":"Node","from":"Syntax","detached":false},{"to":"Node","from":"GetStarted","detached":false}],"Syntax":[{"to":"Syntax","from":"Introduction","detached":false},{"to":"Syntax","from":"TOML","detached":false},{"to":"Syntax","from":"GetStarted","detached":false},{"to":"Syntax","from":"Node","detached":false},{"to":"Syntax","from":"AnchorSyntax","detached":false},{"to":"Syntax","from":"Outputs","detached":false},{"to":"Syntax","from":"Connections","detached":false}],"CLI":[{"to":"CLI","from":"GetStarted","detached":false},{"to":"CLI","from":"Customization","detached":false}],"Connections":[{"to":"Connections","from":"GetStarted","detached":false}],"GetStarted":[{"to":"GetStarted","from":"Introduction","detached":false},{"to":"GetStarted","from":"SourceBuild","detached":false},{"to":"GetStarted","from":"Connections","detached":false}],"Roadmap":[{"to":"Roadmap","from":"Introduction","detached":false},{"to":"Roadmap","from":"Syntax","detached":false},{"to":"Roadmap","from":"GetStarted","detached":false},{"to":"Roadmap","from":"Roadmap","detached":false}]},"lowercase_keymap":{"acknowledgments":"Acknowledgments","syntax":"Syntax","roadmap":"Roadmap","introduction":"Introduction","graph":"Graph","customization":"Customization","outputs":"Outputs","node":"Node","escaping":"Escaping","sourcebuild":"SourceBuild","getstarted":"GetStarted","anchorsyntax":"AnchorSyntax","toml":"TOML","cli":"CLI","redirecttest":"RedirectTest","connections":"Connections"},"meta":{"config":{"_private":false,"about":true,"about_text":"","ascii_dom_ids":false,"content_language":"en","error_poem":true,"footer":true,"footer_credits":false,"footer_date":true,"footer_version":true,"footer_text":"","index_node_count":8,"index_node_list":true,"index_root_node":true,"index_search":true,"node_selector":true,"navbar_search":true,"raw":true,"raw_json":true,"raw_toml":true,"serve_fonts":true,"site_description":"","site_title":"","tree":true,"tree_node_summary":false},"version":{"major":0,"minor":4,"patch":0,"qualifier":"alpha"},"messages":[],"malformed":false},"stats":{"detached":{"PreciousStone":1,"Configuration#mimes":1},"detached_total":2}}