More broken links fixed

Author: edwardalee

docs/reference/target-language-details.mdx

@@ -3052,7 +3052,7 @@ Unlike the C target, the Cpp target implements more of the analysis and setup of
 </ShowIf>
 <ShowIf py>
 
-The Python target is built on top of the C runtime to enable maximum efficiency where possible. It uses the single-threaded C runtime by default but will switch to the multi-threaded C runtime if a physical action is detected. The [threading](target-declaration.mdx#threading) target property can be used to override this behavior.
+The Python target is built on top of the C runtime to enable maximum efficiency where possible. It uses the single-threaded C runtime by default but will switch to the multi-threaded C runtime if a physical action is detected. The [single-threaded](target-declaration.mdx#single-threaded) target property can be used to override this behavior.
 
 Running [lfc](../tools/command-line-tools.mdx) on a `XXX.lf` program that uses the Python target specification on a
 Linux machine will create the following files (other operating systems will have

docs/videos.mdx

@@ -51,7 +51,7 @@ A [video playlist](https://youtube.com/playlist?list=PL4zzL7roKtfXyKE3k8lOwPub9Y
 - [Part II: Hello World](#part-ii-hello-world)
 - [Part III: Target Languages](#part-iii-target-languages)
 - [Part IV: Basic Concepts](#part-iv-basic-concepts)
-- [Part V: Concurrency and Performance](#part-v-concurrency-and-performance)
+- [Part V: Concurrency and Performance](#part-v-concurrency)
 - [Part VI: Research Overview](#part-vi-research-overview)
 - [Slides](https://docs.google.com/presentation/d/14cfIMmkBFwt6NOj2ujVs7YXPAXYsoHgLS2rUgBM-Deg/present?slide=id.g623f095f12_0_0)
 

docs/writing-reactors/actions.mdx

@@ -133,7 +133,7 @@ Action triggered at logical time 603669000 nsec after start.
 ...
 ```
 
-Here, logical time is lagging physical time by a few milliseconds. Note that, unless the [fast option](../reference/target-declaraction#fast) is given, logical time _t_ chases physical time _T_, so _t_ < _T_. Hence, the event being scheduled in the reaction to input `x` is assured of being in the future in logical time.
+Here, logical time is lagging physical time by a few milliseconds. Note that, unless the [fast option](../reference/target-declaration.mdx#fast) is given, logical time _t_ chases physical time _T_, so _t_ < _T_. Hence, the event being scheduled in the reaction to input `x` is assured of being in the future in logical time.
 
 Whereas logical actions are required to be scheduled within a reaction of the reactor that declares the action, physical actions can be scheduled by code that is outside the Lingua Franca system. For example, some other thread or a callback function may call `schedule()`, passing it a physical action. For example:
 

docs/writing-reactors/composing-reactors.mdx

@@ -172,7 +172,7 @@ Connections may include a **logical delay** using the `after` keyword, as follow
 
 where `<time_value>` can be any of the forms described in [Expressions](../reference/expressions.mdx).
 
-The `after` keyword specifies that the logical time of the event delivered to the destination port will be larger than the logical time of the reaction that wrote to source port. The time value is required to be non-negative, but it can be zero, in which case the input event at the receiving end will be one [microstep](<../writing-reactors/actions.mdx#superdense-time>) later than the event that triggered it.
+The `after` keyword specifies that the logical time of the event delivered to the destination port will be larger than the logical time of the reaction that wrote to source port. The time value is required to be non-negative, but it can be zero, in which case the input event at the receiving end will be one [microstep](<../writing-reactors/superdense-time.mdx>) later than the event that triggered it.
 
 ## Physical Connections
 

docs/writing-reactors/multiports-and-banks.mdx

@@ -374,7 +374,7 @@ The syntax `(a.out)+` means "repeat the output port `a.out` one or more times as
 <ShowIfs>
 <ShowIf c cpp py>
 
-Sometimes, we don't want to broadcast messages to all reactors, but need more fine-grained control as to which reactor within a bank receives a message. If we have separate source and destination reactors, this can be done by combining multiports and banks as was shown in [Combining Banks and Multiports](#Combining-Banks-and-Multiports). Setting a value on the index _n_ of the output multiport, will result in a message to the _n_-th reactor instance within the destination bank. However, this pattern gets slightly more complicated, if we want to exchange addressable messages between instances of the same bank. This pattern is shown in the following example:
+Sometimes, we don't want to broadcast messages to all reactors, but need more fine-grained control as to which reactor within a bank receives a message. If we have separate source and destination reactors, this can be done by combining multiports and banks as was shown in [Combining Banks and Multiports](#combining-banks-and-multiports). Setting a value on the index _n_ of the output multiport, will result in a message to the _n_-th reactor instance within the destination bank. However, this pattern gets slightly more complicated, if we want to exchange addressable messages between instances of the same bank. This pattern is shown in the following example:
 
 import C_Interleaved from '../assets/code/c/src/Interleaved.lf';
 import Cpp_Interleaved from '../assets/code/cpp/src/Interleaved.lf';

docs/writing-reactors/preambles.mdx

@@ -326,7 +326,7 @@ Your platform is Linux
 
 By putting import in the `preamble`, the module becomes available in all reactions of this reactor using the `self` modifier.
 
-**Note:** Preambles will be put in the generated Python class for the given reactor, and thus is part of the instance of the reactor. This means that anything you put in the preamble will be specific to a particular reactor instance and cannot be used to share information between different instantiations of the reactor (this is a feature, not a bug, because it helps ensure determinacy). For more information about implementation details of the Python target, see [Implementation Details](<../reference/target-language-details.mdx#python-target-implementation-details>).
+**Note:** Preambles will be put in the generated Python class for the given reactor, and thus is part of the instance of the reactor. This means that anything you put in the preamble will be specific to a particular reactor instance and cannot be used to share information between different instantiations of the reactor (this is a feature, not a bug, because it helps ensure determinacy). For more information about implementation details of the Python target, see [Implementation Details](<../reference/target-language-details.mdx>).
 
 Alternatively, you can define a `preamble` outside any reactor definition. Such a `preamble` can be used for functions such as import or to define a global function. The following example shows importing the [hello](https://github.com/lf-lang/lingua-franca/blob/master/test/Python/src/include/hello.py) module:
 
@@ -432,7 +432,7 @@ Converted string 42 to number 42
 
 ### Using Node Modules
 
-Installing Node.js modules for TypeScript reactors with `npm` is essentially the same as installing modules for an ordinary Node.js program. First, write a Lingua Franca program (`Foo.lf`) and compile it. It may not type check if if you're importing modules in the preamble and you haven't installed the modules yet, but compiling your program will cause the TypeScript code generator to [produce a project](#typescript-target-implementation-details) for your program. There should now be a package.json file in the same directory as your .lf file. Open a terminal and navigate to that directory. You can use the standard [`npm install`](https://docs.npmjs.com/cli/install) command to install modules for your TypeScript reactors.
+Installing Node.js modules for TypeScript reactors with `npm` is essentially the same as installing modules for an ordinary Node.js program. First, write a Lingua Franca program (`Foo.lf`) and compile it. It may not type check if if you're importing modules in the preamble and you haven't installed the modules yet, but compiling your program will cause the TypeScript code generator to [produce a project](../reference/target-language-details.mdx) for your program. There should now be a package.json file in the same directory as your .lf file. Open a terminal and navigate to that directory. You can use the standard [`npm install`](https://docs.npmjs.com/cli/install) command to install modules for your TypeScript reactors.
 
 The important takeaway here is with the package.json file and the compiled JavaScript in the Foo/dist/ directory, you have a standard Node.js program that executes as such. You can modify and debug it just as you would a Node.js program.
 

docs/writing-reactors/time-and-timers.mdx

@@ -215,4 +215,4 @@ import TS_TestCount from '../assets/code/ts/src/TestCount.lf';
 
 This reactor tests its inputs against expected values, which are expected to start with the value given by the `start` parameter and increase by `stride` with each successive input. It expects to receive a total of `num_inputs` input events. It checks the total number of inputs received in its `shutdown` reaction.
 
-The **shutdown** trigger typically occurs at [microstep](../writing-reactors/actions.mdx#superdense-time) 0, but may occur at a larger microstep. See [Superdense Time](../writing-reactors/actions.mdx#superdense-time) and [Termination](../writing-reactors/termination.mdx).
+The **shutdown** trigger typically occurs at [microstep](../writing-reactors/superdense-time.mdx) 0, but may occur at a larger microstep. See [Superdense Time](../writing-reactors/superdense-time.mdx) and [Termination](../writing-reactors/termination.mdx).

versioned_docs/version-0.5.0/reference/target-declaration.mdx

@@ -45,7 +45,7 @@ A target specification may have optional parameters, the names and values of whi
 - [**rust-include**](#rust-include): (Rust only) A set of Rust modules in the generated project.
 - [**scheduler**](#scheduler): (C only) Specification of the scheduler to use.
 - [**single-file-project**](#single-file-project): (Rust only) If true, enables [single-file project layout](target-language-details/?target-languages=rs#file-layout).
-- [**threading**](#threading): Whether to use multiple threads.
+- [**single-threaded**](#single-threaded): Whether to use multiple threads.
 - [**timeout**](#timeout): A time value (with units) specifying the logical stop time of execution. See [Termination](../writing-reactors/termination.mdx).
 - [**workers**](#workers): If using multiple threads, how many worker threads to create.
 

versioned_docs/version-0.5.0/tutorial-videos.mdx

@@ -13,7 +13,7 @@ A [video playlist](https://youtube.com/playlist?list=PL4zzL7roKtfXyKE3k8lOwPub9Y
 - [Part II: Hello World](#part-ii-hello-world)
 - [Part III: Target Languages](#part-iii-target-languages)
 - [Part IV: Basic Concepts](#part-iv-basic-concepts)
-- [Part V: Concurrency and Performance](#part-v-concurrency-and-performance)
+- [Part V: Concurrency and Performance](#part-v-concurrency)
 - [Part VI: Research Overview](#part-vi-research-overview)
 - [Slides](https://docs.google.com/presentation/d/14cfIMmkBFwt6NOj2ujVs7YXPAXYsoHgLS2rUgBM-Deg/present?slide=id.g623f095f12_0_0)
 

versioned_docs/version-0.5.0/writing-reactors/actions.mdx

@@ -133,7 +133,7 @@ Action triggered at logical time 603669000 nsec after start.
 ...
 ```
 
-Here, logical time is lagging physical time by a few milliseconds. Note that, unless the [fast option](../reference/target-declarationd#fast) is given, logical time _t_ chases physical time _T_, so _t_ < _T_. Hence, the event being scheduled in the reaction to input `x` is assured of being in the future in logical time.
+Here, logical time is lagging physical time by a few milliseconds. Note that, unless the [fast option](../reference/target-declaration.mdx#fast) is given, logical time _t_ chases physical time _T_, so _t_ < _T_. Hence, the event being scheduled in the reaction to input `x` is assured of being in the future in logical time.
 
 Whereas logical actions are required to be scheduled within a reaction of the reactor that declares the action, physical actions can be scheduled by code that is outside the Lingua Franca system. For example, some other thread or a callback function may call `schedule()`, passing it a physical action. For example: