doc: Fix various typos and inconsistencies

14 files changed, 33 insertions, 33 deletions

diff --git a/doc/concepts/blob-splitting.md b/doc/concepts/blob-splitting.md
index 2c1529b1..d9b6e67f 100644
--- a/doc/concepts/blob-splitting.md
+++ b/doc/concepts/blob-splitting.md
@@ -75,7 +75,7 @@ to request the chunk digests of a blob from the server, to fetch only
 those chunks that are missing in its local CAS, and to store the fetched
 chunks as well as the reconstructed original blob in its local CAS. If
 the client requests to split a blob, but the server does not support
-blob splitting or if an error occured during the request, the client
+blob splitting or if an error occurred during the request, the client
 falls back to fetch the entire blob.
 
 Blob split procedure
@@ -117,7 +117,7 @@ contains an error, the split operation failed and the client needs to
 fall back to fetch the entire blob. Otherwise, blob splitting was
 successful and the remote server returns an ordered list of
 `chunk_digests` and guarantees that the chunks are available in its CAS
-and that the concatention of all chunks in the given order will result
+and that the concatenation of all chunks in the given order will result
 in the requested blob. The client checks which chunks are available
 locally, fetches only the locally missing chunks from the remote side
 via the `BatchReadBlobs` rpc or the `ByteStream` API, and assembles the
diff --git a/doc/concepts/built-in-rules.md b/doc/concepts/built-in-rules.md
index 5c502668..18964299 100644
--- a/doc/concepts/built-in-rules.md
+++ b/doc/concepts/built-in-rules.md
@@ -95,7 +95,7 @@ by those resolution rules has to be free of semantic conflicts.
 
 The fields `"cmds"`, `"cwd"`, `"sh -c"`, `"out_dirs"`, `"outs"`, and `"env"`
 are evaluated fields where `"cmds"`, `"out_dirs"`, and `"outs"`
-have to evaluate to a list of strings, `"sh -c"` has to evalute to
+have to evaluate to a list of strings, `"sh -c"` has to evaluate to
 a list of strings or `null`, `"env"` has to evaluate to a map
 of strings, and `"cwd"` has to evaluate to a single string naming a non-upwards
 relative path. During their evaluation, the functions `"outs"` and
diff --git a/doc/concepts/computed-roots.md b/doc/concepts/computed-roots.md
index 7007eab4..2bc2094d 100644
--- a/doc/concepts/computed-roots.md
+++ b/doc/concepts/computed-roots.md
@@ -120,7 +120,7 @@ are equal if the defining roots are equal.
 When determining the value of a computed root, as for every export
 target, the provided serve endpoint (if any) is consulted first.
 Only if it is not aware of the root, a local evaluation is carried
-out. This strategy is also applied for tree-stucture roots.
+out. This strategy is also applied for tree-structure roots.
 
 ### `just-mr` support for computed roots
 
@@ -149,7 +149,7 @@ however we do not want to fetch the artifacts of those intermediate
 roots. After all, whole point of the serve service was to use
 dependencies without having them locally.
 
-#### Sytnax for absent computed roots
+#### Syntax for absent computed roots
 
 As for other roots, we let the user specify which roots are to be
 absent. Tools like `just-import-git` will extend their marking of absent
diff --git a/doc/concepts/expressions.md b/doc/concepts/expressions.md
index 5d12d8d2..1367c10b 100644
--- a/doc/concepts/expressions.md
+++ b/doc/concepts/expressions.md
@@ -393,7 +393,7 @@ those) argument(s) to obtain the final result.
    key. Those paths relative to the subdir are taken in canonical
    form; it is an error if non-trivial conflicts arise that way,
    i.e., if two keys that are kept normalize to the same relative
-   path while the repsective values are different.
+   path while the respective values are different.
 
 ##### Binary functions
 
diff --git a/doc/concepts/garbage.md b/doc/concepts/garbage.md
index 278147bb..dc84e54d 100644
--- a/doc/concepts/garbage.md
+++ b/doc/concepts/garbage.md
@@ -133,7 +133,7 @@ CAS is inspected. If found there, then, in this order,
 
 - if the entry is not already in the youngest generation, the chunks
   are promoted to the youngest generation,
-- the object itself is spliced on disk in a temproary file,
+- the object itself is spliced on disk in a temporary file,
 - if the object is a tree, the parts are promoted to the youngest
   generation (only necessary if the large-object entry was not
   found in the youngest generation anyway),
@@ -204,7 +204,7 @@ The compactification step is skipped if the `--all` option is given to
 
 `--no-rotate` and `--all` are incompatible options.
 
-Gargabe Collection for Repository Roots
+Garbage Collection for Repository Roots
 ---------------------------------------
 
 The multi-repository tool `just-mr` often has to create roots: the
diff --git a/doc/concepts/profiling.md b/doc/concepts/profiling.md
index 08bc04ef..ce33302a 100644
--- a/doc/concepts/profiling.md
+++ b/doc/concepts/profiling.md
@@ -75,7 +75,7 @@ output files are in a machine-readable format.
 
 Collection of build data, if desired, should be done routinely.
 For the build-sharing use case it is not known ahead of time,
-which invocation will be the intersting one. Also, statistics over
+which invocation will be the interesting one. Also, statistics over
 invocations are much more informative, if the data is complete (or
 at least sampled in an unbiased way). Therefore, the build-data
 collection should be configured in a configuration file. The
@@ -109,7 +109,7 @@ more keys possibly added in the future).
    is a value derived not only from the command line but also from
    the context of a file (given via `-c`) possibly local on the
    machine `just` was run.
- - The key `"remote"` describes the remote-exeuction endpoint,
+ - The key `"remote"` describes the remote-execution endpoint,
    including the used properties and dispatch list. This allow
    distinguishing builds in different environments (possibly using
    different hardware); this can be relevant both for performance
diff --git a/doc/concepts/rules.md b/doc/concepts/rules.md
index 2e09cb81..785e7009 100644
--- a/doc/concepts/rules.md
+++ b/doc/concepts/rules.md
@@ -193,7 +193,7 @@ following arguments.
 
  - `"cwd"` The directory inside the action root to change to before
    executing the command. The directory has to be given as a string
-   decribing a non-upwards relative path. This field is optional
+   describing a non-upwards relative path. This field is optional
    and defaults to `""`.
 
  - `"env"` The environment in which the command should be executed,
diff --git a/doc/concepts/target-cache.md b/doc/concepts/target-cache.md
index 4ebad03e..3d1547c6 100644
--- a/doc/concepts/target-cache.md
+++ b/doc/concepts/target-cache.md
@@ -235,7 +235,7 @@ choice would violate that projection property we rely upon.
 Consider the following target file (on a content-fixed root) as
 example.
 
-```
+``` jsonc
 { "generated":
   {"type": "generic", "outs": ["out.txt"], "cmds": ["echo Hello > out.txt"]}
 , "export": {"type": "export", "target": "generated"}
diff --git a/doc/future-designs/upwards-symlinks.md b/doc/future-designs/upwards-symlinks.md
index 86238340..66d012f6 100644
--- a/doc/future-designs/upwards-symlinks.md
+++ b/doc/future-designs/upwards-symlinks.md
@@ -4,8 +4,8 @@
 
 ### Existing symlink support
 
-Our buildsystem already supports non-upwards relative symbolic links
-as first-class objects. The reason for chosing this restriction was
+Our build system already supports non-upwards relative symbolic links
+as first-class objects. The reason for choosing this restriction was
 that those can be placed anywhere inside an action directory without
 that directory becoming dependent on the ambient system, regardless
 if symbolic links are followed or inspected via readlink(2).
@@ -23,7 +23,7 @@ is enforced
 - in the output of actions, including output directories,
 - in explicit tree references on `file` roots.
 
-However, it is not eforced when using an explicit tree reference on
+However, it is not enforced when using an explicit tree reference on
 a `git` root as input. The reason is that we want to benefit from
 the fact that trees are already hashed in git repositories so that
 we can get values (and harvest cache hits) without ever looking at
@@ -71,12 +71,12 @@ additional dict as last entry, which may contain the key `"symlink
 level"`; the value for that key is the declared level and has to
 be a non-negative integer. For example,
 - `["SYMLINK", null, "foo", {"symlink level": 3}]` is an explicit
-  symlink referece to a symlink at `foo` in the current module with
+  symlink reference to a symlink at `foo` in the current module with
   declared symlink level 3, and
 - `["TREE", null, "bar", {"symlink level": 4}]` is an explicit tree
   reference to a tree located at `bar` in the current module with
   declared symlink level 4.
-The reason for chosing a dict rather than a positional argument is
+The reason for choosing a dict rather than a positional argument is
 to be prepared for additional declared properties in the future,
 should they become necessary.
 
@@ -117,7 +117,7 @@ this check while keeping the benefits of explicit tree references
 in `git` roots, we keep a cache (in the form of a simple mapping on
 disk) of tree identifiers to their symlink level. This map will be
 garbage collected together with the repository roots (as described
-in the "Gargabe collection for Repository Roots" design).
+in the "Garbage collection for Repository Roots" design).
 
 We also enforce the correctness of the symlink level of action
 outputs: for `"outs"`, if they are a symlink, the level is checked
diff --git a/doc/tutorial/build-delegation.md b/doc/tutorial/build-delegation.md
index 5d597d9e..a8c01ff9 100644
--- a/doc/tutorial/build-delegation.md
+++ b/doc/tutorial/build-delegation.md
@@ -32,7 +32,7 @@ distributes the tree hash to the entities analysing the data.
 As a user of the serve endpoint, by just knowing the tree hash,
 can construct an absent root from it.
 
-```
+``` jsonc
 { "repository":
       { "type": "git tree"
       , "id": "..."
@@ -72,7 +72,7 @@ only access export targets; but while measurement data might have
 some random component, analysing that data typically is a pure
 function. So a simple target file could look as follows.
 
-```
+``` jsonc
 { "": {"type": "export", "target": "stats"}
 , "stats":
   { "type": "generic"
diff --git a/doc/tutorial/computed.md b/doc/tutorial/computed.md
index df455e93..ca1a6845 100644
--- a/doc/tutorial/computed.md
+++ b/doc/tutorial/computed.md
@@ -4,10 +4,10 @@ The general approach of writing a build description side-by-side with
 the source code works in most cases. There are, however, cases where
 the build description depends on the contents of source-like files.
 
-Here we consider a somewhat contrieved example that, however, shows
+Here we consider a somewhat contrived example that, however, shows
 all the various types of derived roots. Let's say we have a very
 regular structure of our code base: one top-level directory for
-each library and if there are depenedencies, then there is a plain
+each library and if there are dependencies, then there is a plain
 file `deps` listing, one entry per line, the libraries depended
 upon. From that structure we want a derived build description that
 is not maintained manually.
@@ -30,7 +30,7 @@ The first step is to write a generator for a single `TARGETS` file. To clearly
 separate the infrastructure files from the sources, we add the generator as
 `utils/generate.py`.
 
-```{.py srcname="utils/generate.py"}
+```{.python srcname="utils/generate.py"}
 #!/usr/bin/env python3
 
 import json
@@ -64,7 +64,7 @@ files (and not just other directories). Additionally, there needs to be
 a top-level target staging all those files that is exported. This can
 be implemented by another script, say `utils/call-generator-targets.py`.
 
-```{.py srcname="utils/call-generator-targets.py"}
+```{.python srcname="utils/call-generator-targets.py"}
 #!/usr/bin/env python3
 
 import json
@@ -117,7 +117,7 @@ the target files. We first write a target file `utils/targets.generate`.
 ```
 
 As we intend to make `utils` a separate logical repository, we also
-add a trival top-level targets file.
+add a trivial top-level targets file.
 
 ```shell
 $ echo {} > utils/TARGETS
@@ -339,7 +339,7 @@ INFO: Target tainted ["test"].
 ```
 
 Obviously, the tree structure has changed, so `"src target tasks
-decription"` target gets rebuild. Also, the `"src target build"`
+description"` target gets rebuild. Also, the `"src target build"`
 target gets rebuild, but if we inspect the log, we see that 2 out
 of 3 actions are taken from cache.
 
diff --git a/doc/tutorial/hello-world.md b/doc/tutorial/hello-world.md
index 25645c73..fc7ff35b 100644
--- a/doc/tutorial/hello-world.md
+++ b/doc/tutorial/hello-world.md
@@ -430,7 +430,7 @@ INFO: Artifacts built, logical paths are:
 $
 ```
 
-The ommitted (i.e., not shown but still built) runfile is the header file. As
+The omitted (i.e., not shown but still built) runfile is the header file. As
 mentioned in the introduction to `just analyse` this is a typical use of that
 second artifact arrangement. We can also have a look at the other information
 that library provides.
diff --git a/doc/tutorial/lint.md b/doc/tutorial/lint.md
index 6005c5d1..f187405e 100644
--- a/doc/tutorial/lint.md
+++ b/doc/tutorial/lint.md
@@ -245,7 +245,7 @@ passed and for the failed tests we format stdout and stderr in some
 easy-to-read way; additionally, we also provide a machine-readable
 summary of the failures.
 
-``` {.py srcname="summary.py"}
+``` {.python srcname="summary.py"}
 #!/usr/bin/env python3
 
 import json
diff --git a/doc/tutorial/tests.md b/doc/tutorial/tests.md
index d4614801..5e6f82a7 100644
--- a/doc/tutorial/tests.md
+++ b/doc/tutorial/tests.md
@@ -119,18 +119,18 @@ INFO: Setup finished, exec ["just","describe","-C","...","tests","greet"]
  - "name"
    | The name of the test
 ...
- - implict dependency
+ - implicit dependency
    | The C/C++ toolchain to use
    - ["@","rules-cc","CC","defaults"]
- - implict dependency
+ - implicit dependency
    | The test runner which starts the actual test binary after providing
    | the respective environment. The runner also takes care of capturing
    | stdout/stderr and timing information.
    - ["@","rules-cc","CC/test","runner"]
- - implict dependency
+ - implicit dependency
    | The shell toolchain to use PATH from for calling the summary action
    - ["@","rules-cc","shell","defaults"]
- - implict dependency
+ - implicit dependency
    | Tool to aggregate the results of individual test runs (for flakyness
    | detection) to an overall test result. If more fields than the result
    | itself is needed, those can be specified using the "summarizer" rule.
@@ -493,4 +493,4 @@ $
 As the output structure is again one tree per test, test suits can
 be put into other test suites; to avoid conflicts, the `"stage"`
 field of the test suite can be used to put all outputs into a
-suite-specific sudirectory.
+suite-specific subdirectory.