Merge pull request #123 from bonsai-rx/align-docs

glopesdev · web-flow · commit 0c7cb5621f23 · 2025-02-04T09:11:03.000Z
Ensure consistent xref style across articles
diff --git a/articles/cli.md b/articles/cli.md
@@ -63,7 +63,7 @@ Application mode is useful for batch processing, interop with other languages an
 > ```cmd
 > bonsai workflow.bonsai --no-editor > output.txt
 > ```
-> Values can be written to the standard output using the [**WriteLine**](xref:Bonsai.IO.WriteLine) operator.
+> Values can be written to the standard output using the [`WriteLine`](xref:Bonsai.IO.WriteLine) operator.
 
 ## Passing parameter values to workflows
 
diff --git a/articles/create-package.md b/articles/create-package.md
@@ -118,4 +118,4 @@ The Bonsai language can be extended with custom packages, which are installed an
     > If you have your custom package installed in the same editor used to debug the source code, Bonsai will prefer the installed package over the compiled source code library. In this case, either uninstall the package, or use a local Bonsai installation.
 
     > [!Note]
-    > If you would like to share the package with the broader Bonsai community, consider publishing it to [**NuGet**](https://www.nuget.org/packages/manage/upload) by creating a `NuGet` account and uploading the `.nupkg` file. Ensure the `PackageType` field is properly defined before submission.
+    > If you would like to share the package with the broader Bonsai community, consider publishing it to [NuGet](https://www.nuget.org/packages/manage/upload) by creating a NuGet account and uploading the `.nupkg` file. Ensure the `PackageType` field is properly defined before submission.
diff --git a/articles/expressions-format.md b/articles/expressions-format.md
@@ -10,7 +10,7 @@ If no format string is specified, the default [ToString](xref:System.Object.ToSt
 ### Examples
 
 > [!Note]
-> Below you can find various applications of the `Format` operator. For more formatting examples and a comprehensive list of supported format strings for different data types, see the extended discussion section of the [**String.Format**](xref:System.String.Format*) method.
+> Below you can find various applications of the `Format` operator. For more formatting examples and a comprehensive list of supported format strings for different data types, see the extended discussion section of the [`String.Format`](xref:System.String.Format*) method.
 
 #### Insert a string
 
diff --git a/articles/expressions-groupworkflow.md b/articles/expressions-groupworkflow.md
@@ -8,6 +8,6 @@ The workflow nested inside `GroupWorkflow` specifies the entire behavior of this
 All observable sequences passed as arguments to the outer `GroupWorkflow` will be routed to the inner [WorkflowInput](xref:Bonsai.Expressions.WorkflowInputBuilder) nodes. Conversely, all notifications emitted by the sequence connected to the single [WorkflowOutput](xref:Bonsai.Expressions.WorkflowOutputBuilder) node will be passed to any observers of the group node. It is possible to subscribe multiple times to the same group, in which case the nested workflow will run potentially in parallel and is considered to be reentrant.
 
 > [!Tip]
-> Use [**ExternalizedMapping**](xref:Bonsai.Expressions.ExternalizedMappingBuilder) operators to expose configurable properties when selecting the nested workflow node. Externalized properties in a nested workflow work the same way as regular properties in other operators. They can be further externalized as part of other nested operators or dynamically assigned using [**PropertyMapping**](xref:Bonsai.Expressions.PropertyMappingBuilder) or [**InputMapping**](xref:Bonsai.Expressions.InputMappingBuilder) operators.
+> Use [`ExternalizedMapping`](xref:Bonsai.Expressions.ExternalizedMappingBuilder) operators to expose configurable properties when selecting the nested workflow node. Externalized properties in a nested workflow work the same way as regular properties in other operators. They can be further externalized as part of other nested operators or dynamically assigned using [`PropertyMapping`](xref:Bonsai.Expressions.PropertyMappingBuilder) or [`InputMapping`](xref:Bonsai.Expressions.InputMappingBuilder) operators.
 
 [!include[SharedState](~/articles/expressions-sharedstate.md)]
diff --git a/articles/expressions-includeworkflow.md b/articles/expressions-includeworkflow.md
@@ -8,6 +8,6 @@ The `IncludeWorkflow` operator works in exactly the same way as [GroupWorkflow](
 All observable sequences passed as arguments to the outer `IncludeWorkflow` will be routed to the inner [WorkflowInput](xref:Bonsai.Expressions.WorkflowInputBuilder) nodes. Conversely, all notifications emitted by the sequence connected to the single [WorkflowOutput](xref:Bonsai.Expressions.WorkflowOutputBuilder) node will be passed to any observers of the include workflow node. It is possible to subscribe multiple times to the same include workflow, in which case the nested workflow will run potentially in parallel and is considered to be reentrant.
 
 > [!Note]
-> Externalized properties contained inside the included workflow will be exposed when selecting the `IncludeWorkflow` node. Any changes to the values of these properties can be recovered, even if the included workflow is reused multiple times in different parts of the program. They can also be further externalized as part of other nested operators or dynamically assigned using [**PropertyMapping**](xref:Bonsai.Expressions.PropertyMappingBuilder) or [**InputMapping**](xref:Bonsai.Expressions.InputMappingBuilder) operators.
+> Externalized properties contained inside the included workflow will be exposed when selecting the `IncludeWorkflow` node. Any changes to the values of these properties can be recovered, even if the included workflow is reused multiple times in different parts of the program. They can also be further externalized as part of other nested operators or dynamically assigned using [`PropertyMapping`](xref:Bonsai.Expressions.PropertyMappingBuilder) or [`InputMapping`](xref:Bonsai.Expressions.InputMappingBuilder) operators.
 
 [!include[SharedState](~/articles/expressions-sharedstate.md)]
diff --git a/articles/expressions-propertymapping-multiple.md b/articles/expressions-propertymapping-multiple.md
@@ -6,6 +6,6 @@ title: "PropertyMappingMultiple"
 Multiple properties can be mapped simultaneously from the same source sequence when using `PropertyMapping`. You can select which properties to map by using the editors available in the property grid. For each mapped property you must specify a source selector, i.e. an expression specifying which members of the input data type are used to assign values to the mapped property.
 
 > [!Note]
-> If the type of the selected member does not match the type of the property, a conversion is attempted. If no compatible conversion is available, the compiler checks whether it is possible to construct the corresponding data type from the selected members. For example, it would be possible to map to a [**Point**](xref:OpenCV.Net.Point) type by selecting two numeric values from the source sequence. In this case, the values would be used to construct a new point instance by assigning them to the X and Y parameters of the type constructor.
+> If the type of the selected member does not match the type of the property, a conversion is attempted. If no compatible conversion is available, the compiler checks whether it is possible to construct the corresponding data type from the selected members. For example, it would be possible to map to a [`Point`](xref:OpenCV.Net.Point) type by selecting two numeric values from the source sequence. In this case, the values would be used to construct a new point instance by assigning them to the X and Y parameters of the type constructor.
 
 In each property mapping operator, all mapped properties are updated at the same time every time the source sequence sends out a new value. It is also possible to connect property mapping operators to multiple target nodes.
diff --git a/articles/expressions-propertysource.md b/articles/expressions-propertysource.md
@@ -1,4 +1,4 @@
 Property sources expose a value which can be set from the property grid and also generate an observable sequence that emits a notification whenever the property value changes, starting with the initial property value.
 
 > [!Tip]
-> Property sources are commonly used to create new configuration parameters with custom names for nested workflows. To expose and rename a property source, use [**Property Mapping**](xref:property-mapping#externalized-properties) to externalize the property value and set its [`DisplayName`](xref:Bonsai.Expressions.ExternalizedMapping.DisplayName).
+> Property sources are commonly used to create new configuration parameters with custom names for nested workflows. To expose and rename a property source, use [`Property Mapping`](xref:property-mapping#externalized-properties) to externalize the property value and set its [`DisplayName`](xref:Bonsai.Expressions.ExternalizedMapping.DisplayName).
diff --git a/articles/expressions-unit.md b/articles/expressions-unit.md
@@ -6,4 +6,4 @@ title: "Unit"
 The `Unit` operator generates a sequence returning the singleton unit object, if no input sequence is provided. Otherwise, it will convert all elements in the source sequence to the <xref href="System.Reactive.Unit"/> type.
 
 > [!Tip]
-> `Unit` is most commonly used for converting separate branches with different types into a common type signature, so they can be combined using control flow operators such as [**Merge**](xref:Bonsai.Reactive.Merge) or [**Concat**](xref:Bonsai.Reactive.Concat).
+> `Unit` is most commonly used for converting separate branches with different types into a common type signature, so they can be combined using control flow operators such as [`Merge`](xref:Bonsai.Reactive.Merge) or [`Concat`](xref:Bonsai.Reactive.Concat).
diff --git a/articles/reactive-createobservable.md b/articles/reactive-createobservable.md
@@ -8,6 +8,6 @@ title: CreateObservable
 For each notification in the source sequence, `CreateObservable` constructs a new instance of the asynchronous operation specified in the nested workflow and emits the operation exposed as an observable sequence. However, `CreateObservable` does not itself subscribe to the sequence, which means the logic inside the nested workflow will not run unless the emitted observables are subscribed downstream.
 
 > [!Note]
-> You can manipulate and schedule each of the emitted observable sequences downstream using higher-order operators such as [**Merge**](xref:Bonsai.Reactive.Merge), [**Concat**](xref:Bonsai.Reactive.Concat) or [**Switch**](xref:Bonsai.Reactive.Switch).
+> You can manipulate and schedule each of the emitted observable sequences downstream using higher-order operators such as [`Merge`](xref:Bonsai.Reactive.Merge), [`Concat`](xref:Bonsai.Reactive.Concat) or [`Switch`](xref:Bonsai.Reactive.Switch).
 
 The input to the nested workflow represents the element passed as an argument to the asynchronous operation. If the input is itself an observable sequence, the [WorkflowInput](xref:Bonsai.Expressions.WorkflowInputBuilder) node will subscribe to all the values in the sequence when the asynchronous operation is finally launched. Otherwise, the input will emit a single value containing the stored argument value.
diff --git a/articles/reactive-first.md b/articles/reactive-first.md
@@ -8,9 +8,9 @@ title: First
 If the sequence has no elements, `First` will terminate with an error.
 
 > [!Tip]
-> If you are interested in finding the first element that meets some criteria, consider using the [**Condition**](xref:Bonsai.Reactive.Condition) operator before `First`.
+> If you are interested in finding the first element that meets some criteria, consider using the [`Condition`](xref:Bonsai.Reactive.Condition) operator before `First`.
 
 > [!Warning]
-> There are subtle but important differences between using the `First` operator and [**`Take(1)`**](xref:Bonsai.Reactive.Take):
+> There are subtle but important differences between using the `First` operator and [`Take(1)`](xref:Bonsai.Reactive.Take):
 >   - When the source sequence has no elements, `Take(1)` will complete successfully, while `First` will throw an error.
 >   - When the source sequence emits the first element, `Take(1)` will immediately cancel the subscription to the source sequence before emitting the notification. `First`, on the other hand, will emit the notification and only afterwards cancel the subscription to the source sequence.
diff --git a/articles/reactive-firstordefault.md b/articles/reactive-firstordefault.md
@@ -8,9 +8,9 @@ title: FirstOrDefault
 If the sequence has no elements, `FirstOrDefault` will emit a default value before terminating successfully.
 
 > [!Tip]
-> If you are interested in finding the first element that meets some criteria, consider using the [**Condition**](xref:Bonsai.Reactive.Condition) operator before `FirstOrDefault`.
+> If you are interested in finding the first element that meets some criteria, consider using the [`Condition`](xref:Bonsai.Reactive.Condition) operator before `FirstOrDefault`.
 
 > [!Warning]
-> There are subtle but important differences between using the `FirstOrDefault` operator and [**`Take(1)`**](xref:Bonsai.Reactive.Take):
+> There are subtle but important differences between using the `FirstOrDefault` operator and [`Take(1)`](xref:Bonsai.Reactive.Take):
 >   - When the source sequence has no elements, `Take(1)` will complete successfully with no emitted values, while `FirstOrDefault` will emit a default value before terminating successfully.
 >   - When the source sequence emits the first element, `Take(1)` will immediately cancel the subscription to the source sequence before emitting the notification. `FirstOrDefault`, on the other hand, will emit the notification and only afterwards cancel the subscription to the source sequence.
diff --git a/articles/reactive-groupby.md b/articles/reactive-groupby.md
@@ -9,6 +9,6 @@ The `GroupBy` operator can be used to separate, or demultiplex, the elements fro
 <xref href="Bonsai.Reactive.GroupBy.KeySelector"/>. Each element from the sequence will be routed to the correct group according to its key. Groups are created and emitted the first time that an element with a new distinct key value is received from the source sequence.
 
 > [!Note]
-> You can manipulate and schedule each of the group sequences downstream using other higher-order operators such as [**Merge**](xref:Bonsai.Reactive.Merge), [**Concat**](xref:Bonsai.Reactive.Concat) or [**Switch**](xref:Bonsai.Reactive.Switch).
+> You can manipulate and schedule each of the group sequences downstream using other higher-order operators such as [`Merge`](xref:Bonsai.Reactive.Merge), [`Concat`](xref:Bonsai.Reactive.Concat) or [`Switch`](xref:Bonsai.Reactive.Switch).
 
 The members used to generate the elements in each group sequence can be optionally specified using the <xref href="Bonsai.Reactive.GroupBy.ElementSelector"/> property. If no element selector is specified, the original values from the source sequence will be used.
diff --git a/articles/reactive-resubscription.md b/articles/reactive-resubscription.md
@@ -1,5 +1,5 @@
 > [!Tip]
-> The subscription side-effects (e.g. opening a file, initializing hardware connections) of all upstream operators will be repeated upon termination and resubscription to the source sequence. Sometimes this may be undesirable. For example logging side-effects introduced by [**Sink**](xref:operators#sink) nodes may create extra files on each subscription. To shield operators from these effects, consider moving affected operators downstream from the resubscription operator, or moving the resubscription operator itself further upstream.
+> The subscription side-effects (e.g. opening a file, initializing hardware connections) of all upstream operators will be repeated upon termination and resubscription to the source sequence. Sometimes this may be undesirable. For example logging side-effects introduced by [`Sink`](xref:operators#sink) nodes may create extra files on each subscription. To shield operators from these effects, consider moving affected operators downstream from the resubscription operator, or moving the resubscription operator itself further upstream.
 
 > [!Caution]
 > All resubscription operators should be applied with care to anonymous branch points in the workflow, since dangling branches operate independently from each other, and from the subscription to the source sequence. For more details, see @subjects#branching-subjects.
diff --git a/articles/reactive-selectmany.md b/articles/reactive-selectmany.md
@@ -10,4 +10,4 @@ For each notification in the source sequence, `SelectMany` constructs and subscr
 The input to the nested workflow represents the element passed as an argument to the asynchronous operation. If the input is itself an observable sequence, the [WorkflowInput](xref:Bonsai.Expressions.WorkflowInputBuilder) node will subscribe to all the values in the sequence when the asynchronous operation is launched. Otherwise, the input will emit a single value containing the stored argument value.
 
 > [!Tip]
-> `SelectMany` is one of the most versatile reactive operators and can be used as a primitive building block on which to build a large number of more complex reactive operators, including reactive state machines. See the [**State Machines**](xref:state-machines-tutorial) tutorial for examples.
+> `SelectMany` is one of the most versatile reactive operators and can be used as a primitive building block on which to build a large number of more complex reactive operators, including reactive state machines. See the [State Machines tutorial](xref:state-machines-tutorial) for examples.
diff --git a/articles/reactive-visualizer.md b/articles/reactive-visualizer.md
@@ -8,4 +8,4 @@ title: Visualizer
 The `Visualizer` operator is a [Sink](xref:Bonsai.Reactive.Sink) which uses the nested workflow to specify a reactive visualizer function over the elements of the source sequence. `Visualizer` emits all values from the source sequence directly without modification, and the nested sequence is subscribed to purely for its side-effects.
 
 > [!Note]
-> All notifications emitted by the inner [**WorkflowOutput**](xref:Bonsai.Expressions.WorkflowOutputBuilder) node are ignored. However, the type visualizer assigned to the nested workflow output will be considered as the default visualizer of the outer node.
+> All notifications emitted by the inner [`WorkflowOutput`](xref:Bonsai.Expressions.WorkflowOutputBuilder) node are ignored. However, the type visualizer assigned to the nested workflow output will be considered as the default visualizer of the outer node.
diff --git a/articles/reactive-window.md b/articles/reactive-window.md
@@ -10,4 +10,4 @@ The `Window` operator groups the notifications of the source sequence into new o
 If a new window is created before the previous window is closed, then window will overlap, and any elements emitted during this period will be included in both windows. If at any moment there is no open window, elements emitted from the source sequence will be dropped.
 
 > [!Note]
-> You can manipulate and schedule each of the windows downstream using other higher-order operators such as [**Merge**](xref:Bonsai.Reactive.Merge), [**Concat**](xref:Bonsai.Reactive.Concat) or [**Switch**](xref:Bonsai.Reactive.Switch).
+> You can manipulate and schedule each of the windows downstream using other higher-order operators such as [`Merge`](xref:Bonsai.Reactive.Merge), [`Concat`](xref:Bonsai.Reactive.Concat) or [`Switch`](xref:Bonsai.Reactive.Switch).
diff --git a/articles/reactive-windowcount.md b/articles/reactive-windowcount.md
@@ -10,4 +10,4 @@ title: WindowCount
 If no skip value is provided, the windows will be strictly non-overlapping, with a new window beginning when the previous window ends. If the skip value is less than the specified number of elements, windows will be overlapping, with a new window created every `Skip` notifications. Finally, if the skip value is greater than the specified number of elements, there will be a gap between each window where elements from the source sequence will be dropped.
 
 > [!Note]
-> You can manipulate and schedule each of the windows downstream using other higher-order operators such as [**Merge**](xref:Bonsai.Reactive.Merge), [**Concat**](xref:Bonsai.Reactive.Concat) or [**Switch**](xref:Bonsai.Reactive.Switch).
+> You can manipulate and schedule each of the windows downstream using other higher-order operators such as [`Merge`](xref:Bonsai.Reactive.Merge), [`Concat`](xref:Bonsai.Reactive.Concat) or [`Switch`](xref:Bonsai.Reactive.Switch).
diff --git a/articles/reactive-windowtime.md b/articles/reactive-windowtime.md
@@ -10,4 +10,4 @@ The `WindowTime` operator groups the notifications of the source sequence into n
 If no `TimeShift` is provided, the windows will be strictly non-overlapping, with a new window beginning when the previous window ends. If `TimeShift` is smaller than `TimeSpan`, windows will be overlapping, with a new buffer created every `TimeShift` interval. Finally, if `TimeShift` is larger than `TimeSpan`, there will be a time gap between each window where elements from the source sequence may be dropped.
 
 > [!Note]
-> You can manipulate and schedule each of the windows downstream using other higher-order operators such as [**Merge**](xref:Bonsai.Reactive.Merge), [**Concat**](xref:Bonsai.Reactive.Concat) or [**Switch**](xref:Bonsai.Reactive.Switch).
+> You can manipulate and schedule each of the windows downstream using other higher-order operators such as [`Merge`](xref:Bonsai.Reactive.Merge), [`Concat`](xref:Bonsai.Reactive.Concat) or [`Switch`](xref:Bonsai.Reactive.Switch).
diff --git a/articles/scripting-extensions.md b/articles/scripting-extensions.md
