Fixes issue #1133 (consistent naming of statechart concepts) and a multitude of other issues (#1597)

* First changes

* Issue 1133: intermediate status

Documentation review with many, many more or less minor changes

* Documentation: build bug fixed

* Many more or less minor changes

* Anchors straightened, links checked.

* Issue 1133: multiple fixes

* Useful tools added

* Issue 1133: Number of Textile files fixed

* Issue 1133: Four links fixed

.gitignore

@@ -1 +1,3 @@
 *.sctunit.xml
+
+plugins/org\.yakindu\.sct\.doc\.user/yakindu_license\.log

plugins/org.yakindu.sct.doc.user/build.xml

@@ -147,6 +147,7 @@
                 <include name="user-guide/generating_code.textile" />
                 <include name="user-guide/generating_code_headless.textile" />
                 <include name="user-guide/sctunit.textile" />
+                <!-- <include name="user-guide/glossary.textile" /> -->
             </fileset>
 
             <!-- Check whether we have all the expected textile source files – no more, no less: -->
@@ -324,6 +325,7 @@
                         <file name="user-guide/generating_code.textile" />
                         <file name="user-guide/generating_code_headless.textile" />
                         <file name="user-guide/sctunit.textile" />
+                        <file name="user-guide/glossary.textile" />
                     </filelist>
                 </textile-files>
                 <image-files>

plugins/org.yakindu.sct.doc.user/misc/checkLinks_w3c.sh

@@ -0,0 +1,28 @@
+#!/bin/sh
+
+#
+# Check links in the generated documentation. This script runs on Linux and
+# assumes
+# - the W3C "checklink" program to be installed,
+# - the generated documentation being "online", i.e. served by a web server.
+#
+# Use "python3 -m http.server 8082" to start a web server that serves the current directory.
+#
+
+prefix="http://localhost:8082/"
+
+checklink --broken --dir-redirects \
+--recursive --depth 1 \
+--exclude https://github.com/Yakindu/.* \
+${prefix}user-guide/advanced_simulation.html \
+${prefix}user-guide/c-domain.html \
+${prefix}user-guide/editing_statecharts.html \
+${prefix}user-guide/generating_code_headless.html \
+${prefix}user-guide/generating_code.html \
+${prefix}user-guide/glossary.html \
+${prefix}user-guide/overview.html \
+${prefix}user-guide/sctunit.html \
+${prefix}user-guide/simulating_statecharts.html \
+${prefix}user-guide/statechart_language.html \
+${prefix}tutorials/tutorials.html \
+2>&1 | tee log.txt

plugins/org.yakindu.sct.doc.user/misc/findHeaders.pl

@@ -0,0 +1,37 @@
+#!/usr/bin/perl -w
+
+use Switch;
+
+# $prefix = "edit";
+
+sub processTableLine {
+    $_ = "$_[0]";
+
+    s|width="(.*)?"||g;
+    s|cellpadding="(.*)?"||g;
+    s|cellspacing="(.*)?"||g;
+
+    s|<col (.*)?>||g;
+
+    return $_;
+}
+
+
+
+while (<>)
+{
+    $a = $_;
+
+    # Headers:
+    if ($a =~ m|^h\d\(#|) {
+	if ($a =~ m|-|) {
+	    print $_;
+	}
+    }
+
+    # Links:
+#    if (m|":#|g) {
+#	print;
+#    }
+
+}

plugins/org.yakindu.sct.doc.user/plugin.xml

@@ -12,6 +12,7 @@
         <toc file="help/user-guide/simulating_statecharts-toc.xml" primary="false"/>
         <toc file="help/user-guide/advanced_simulation-toc.xml" primary="false"/>
         <toc file="help/user-guide/c-domain-toc.xml" primary="false"/>
+        <toc file="help/user-guide/typescript-domain-toc.xml" primary="false"/>
         <toc file="help/user-guide/statechart_language-toc.xml" primary="false"/>
         <toc file="help/user-guide/generating_code-toc.xml" primary="false"/>
         <toc file="help/user-guide/generating_code_headless-toc.xml" primary="false"/>

plugins/org.yakindu.sct.doc.user/src/user-guide/c-domain.textile

@@ -5,7 +5,7 @@ p.
 
 p(edit-on-github). "Edit on GitHub":https://github.com/Yakindu/statecharts/edit/master/plugins/org.yakindu.sct.doc.user/src/user-guide/c-domain.textile
 
-h1(#cdom_deep-c-integration). Deep C integration: Integrating your C source code with your state machines
+h1(#cdom_deep_c_integration). Deep C integration: Integrating your C source code with your state machines
 
 h2(#cdom_introduction). Introduction
 
@@ -21,7 +21,7 @@ Instead of "types, structs, and unions", subsequently we will speak of "types" o
 p. The subsequent sections will explain how to use the C integration in practice, using a sample project. In this example, we will define some geometry types like _Point_ or _Triangle_ in C header files and demonstrate how to make them available and use them in a statechart model.
 
 
-h2(#cdom_creating-a-new-c-project). Creating a new C project
+h2(#cdom_creating_a_new_c_project). Creating a new C project
 
 # In the Eclipse main menu, select _File → New → Project…_. The _New Project_ wizard opens.
 # Select _C/C++ → C Project_.<br/>!images/cdom_geometry_010_new_c_project_010.png(Creating a new C project)!
@@ -36,19 +36,19 @@ h2(#cdom_creating-a-new-c-project). Creating a new C project
 # Eclipse asks whether it should associate this kind of project with the C/C++ perspective. Usually this is what you want, so set a checkmark at _Remember my decision_ and click _Yes_.
 # Eclipse creates the C project, here *Geometry*.
 
-h2(#cdom_creating-a-c-header-file). Creating a C header file
+h2(#cdom_creating_a_c_header_file). Creating a C header file
 
 Now we can create a C header file specifying our own C type definitions which we can use in a state machine later. In order to create the file, let's proceed as follows:
 
 # In the project explorer view, right-click on the project. The context menu opens.
 # In the context menu, select _New → Header File_.<br/>!images/cdom_geometry_020_new_header_file_010.png(Creating a C header file)!
-# The dialog _New Header File_ is shown. Specify the name of the header file. Here we choose *point.h*.<br/>!images/cdom_geometry_020_new_header_file_020.png(Selecting a header file name)!
+# The dialog _New Header File_ is shown. Specify the name of the header file. Here we choose *point.h*.<br/>!images/cdom_geometry_020_new_header_file_020.png(Selecting a header filename)!
 # Click _Finish_. 
 # The header file *point.h* is created.<br/>
 
-h2(#cdom_defining-a-c-struct). Defining a C struct
+h2(#cdom_defining_a_c_struct). Defining a C struct
 
-In the created header file we define a struct type named *Point*, which we will later use in a statechart. A (two-dimensional) point consists of an _x_ and a _y_ coordinate. We choose *int16_t* to represent a coordinate, i.&#8239;e. a 16-bit signed integer. The complete header file containing the struct definition looks like this:
+In the created header file we define a struct type named *Point*, which we will later use in a statechart. A (two-dimensional) point consists of an _x_ and a _y_ coordinate. We choose *int16_t* to represent a coordinate, i.e. a 16-bit signed integer. The complete header file containing the struct definition looks like this:
 
 bc.. 
 /*
@@ -72,9 +72,9 @@ bq.. *Please note:*
 
 In C it is possible to define structs, unions and enums without a _typedef_. They can be referenced by using the corresponding qualifying keyword (_struct_, _union_, or _enum_, respectively). As the statechart language does *not* support these qualifiers, the usage of struct, union and enumeration types is currently restricted to those defined by a _typedef_.
 
-h2(#cdom_using-a-c-struct-in-a-statechart). Using C types in a statechart
+h2(#cdom_using_a_c_struct_in_a_statechart). Using C types in a statechart
 
-h3(#cdom_creating-a-statechart-model). Creating a statechart model
+h3(#cdom_creating_a_statechart_model). Creating a statechart model
 
 Let's create a statechart model now to make use of the C type _Point_ we have just defined.
 
@@ -84,7 +84,7 @@ Let's create a statechart model now to make use of the C type _Point_ we have ju
 # Click _Finish_. If Eclipse asks you whether to switch to the _YAKINDU Modeling_ perspective, please confirm.
 # The new statechart model is created:<br/>!images/cdom_geometry_030_new_statechart_model_030.png(New statechart model)!
 
-h3(#cdom_defining-a-c-type-variable-in-a-statechart). Defining a C-type variable in a statechart
+h3(#cdom_defining_a_c-type_variable_in_a_statechart). Defining a C-type variable in a statechart
 
 Variables are defined in the definition section on the left-hand side of the statechart editor. Double-click into the definition section to edit it.
 
@@ -93,13 +93,13 @@ In order to make use of the struct defined above we have to import the _point.h_
 bc. 
 import: "point.h"
 
-With the definitions from _point.h_ at hand, we can declare a variable *pointA* of the _Point_ type. In the statechart's definition section, enter the following text:
+With the definitions from _point.h_ at hand, we can declare a variable _pointA_ of the _Point_ type. In the statechart's definition section, enter the following text:
 
 bc. 
 interface:
 	var pointA:
 
-On the right-hand side of the colon in the variable declaration, the variable's type must follow. In order to see which types are available, press <code>[Ctrl]+[Space]</code>. The content assist opens and shows the C types available, depending on the headers imported within your statechart, i.&#8239;e.
+On the right-hand side of the colon in the variable declaration, the variable's type must follow. In order to see which types are available, press @[Ctrl+Space]@. The content assist opens and shows the C types available, depending on the headers imported within your statechart, i.e.
 * the C basic standard types,
 * the C99 types, provided by including _stdint.h_,
 * the self-defined _Point_ type, provided by including _point.h_,
@@ -115,7 +115,7 @@ Selecting the _Point_ menu entry completes the variable definition:
 
 p=. A _Point_ variable
 
-h3(#cdom_using-a-c-type-variable-in-a-statechart). Using a C-type variable in a statechart
+h3(#cdom_using_a_c-type_variable_in_a_statechart). Using a C-type variable in a statechart
 
 A statechart variable with a C type can be used everywhere a "normal" statechart variable can be used.
 
@@ -127,18 +127,18 @@ interface:
     var pointA: Point
     in event tick
 
-The statechart below uses these variables in various places, i.&#8239;e. in transition actions, in internal actions, and in guard conditions.
+The statechart below uses these variables in various places, i.e. in transition actions, in internal actions, and in guard conditions.
 
 !images/cdom_geometry_050_using_c_type_variables_010.png(Using C-type variables)!
 
 p=. Using C-type variables
 
-Variables of primitive types like @var count: int8_t@ are accessed as expected, e.&#8239;g. @count = 0@ or @count += 1;@
+Variables of primitive types like @var count: int8_t@ are accessed as expected, e.g. @count = 0@ or @count += 1;@
 
 The dot notation is used to access structure elements. For example, @pointA.x = 0; pointA.y = 0@ sets *pointA* to the origin of the coordinate system.
 
 
-h3(#cdom_the-statechart-type-system). The statechart type system
+h3(#cdom_the_statechart_type_system). The statechart type system
 
 When parsing a C header file YAKINDU Statechart Tools are mapping the C data types to an internal type system. You can open a C header file in Eclipse with the _Sample Reflective Ecore Model Editor_ to see how the mapping result looks like.
 
@@ -146,9 +146,9 @@ In case you are interested in the EMF model underlying SCT's type system, you ca
 
 
 
-h2(#cdom_imports-and-includes). Imports and includes
+h2(#cdom_imports_and_includes). Imports and includes
 
-h3(#cdom_importing-a-c-header). Importing a C header
+h3(#cdom_importing_a_c_header). Importing a C header
 
 YAKINDU Statechart Tools gives you direct access to C header files within the statechart model. This saves time during development, especially while integrating your state machine with your C program. In general you can import (include) all C header files residing in the same project as well as those header files that are available on one of the CDT project's include paths, see _Properties → C/C++ General → Paths and Symbols_ in the context menu of your C project.
 
@@ -178,7 +178,7 @@ interface:
 
 
 
-h2(#cdom_data-structure-traversal-via-dot-notation). Data structure traversal via dot notation
+h2(#cdom_data_structure_traversal_via_dot_notation). Data structure traversal via dot notation
 
 The dot notation to access structure members can traverse an arbitrary number of stages. As an example, let's define a datatype named _Triangle_. A triangle is defined by three points. Using dot notation in a statechart, you can navigate from a triangle to its individual points and further on to the points' coordinates.
 
@@ -218,7 +218,7 @@ Pointers are a core feature of the C programming language. YAKINDU Statechart To
 * pass pointers as parameters to functions, and
 * receive a pointer as a functions return value.
 
-h3(#cdom_declaring-pointer-variables). Declaring pointer variables
+h3(#cdom_declaring_pointer_variables). Declaring pointer variables
 
 Pointer variables are declared in a statechart's definition section as shown in the following example:
 
@@ -239,7 +239,7 @@ bq.. *Please note:*
 When closing the type specification in a pointer declaration with angle brackets, e.&nbsp;g. @pointer<pointer<int32_t> >@, the @>@ characters must be separated from each other by one or more white space characters. Writing e.&nbsp;g. @pointer<pointer<int32_t>>@ would result in an error. This restrictions pertains to the current release candidate of YAKINDU Statechart Tools PRO only and will be fixed in the final release.
 
 
-h3(#cdom_using-pointer-variables). Using pointer variables
+h3(#cdom_using_pointer_variables). Using pointer variables
 
 In order to actually assign a pointer to a pointer variable, you have to get hold of that pointer. To retrieve the pointer to a variable _v_, use _v_'s extension function _pointer_. That is, for a variable _v_, the expression _v.pointer_ evaluates to a pointer to _v_. Each variable has the _pointer_ extension function.
 
@@ -380,7 +380,7 @@ The statechart simulation
 * transitions to the *A is larger* state, because its guard condition is fulfilled, and
 * stops, waiting for the _compare_size_ event to occur.
 
-h3(#cdom_inspecting-c-data-structures). Inspecting C data structures
+h3(#cdom_inspecting_c_data_structures). Inspecting C data structures
 
 !images/cdom_geometry_080_simulation_020_inspecting.png(Inspecting C data structures)!
 
@@ -397,7 +397,7 @@ Simple C variables and fields in C data structure are *not* initialized. Never t
 
 Even if the _Point_ data structures in the example above look like having been initialized to defined values, they are not. Without going into details, in C, variables are generally *not* initialized. This also holds for statechart variables from the C integration. If you are reading a variable, make sure you have written to it before. Otherwise you might get surprising and non-deterministic results.
 
-h3(#cdom_modifying-c-data-structures). Modifying C data structures
+h3(#cdom_modifying_c_data_structures). Modifying C data structures
 
 Change a variable's or field's value as follows:
 # Click on the _value_ displayed in the simulation view.
@@ -418,9 +418,9 @@ In the example, click _compare_size_ to trigger the event. The state machine tra
 p=. Rectangle areas modified and rechecked
 
 
-h2(#cdom_looking-up-a-type-definition). Looking up a type definition
+h2(#cdom_looking_up_a_type_definition). Looking up a type definition
 
-Given a variable definition in a statechart's definition section, you can lookup the corresponding type definition. The definition section must be in editing mode, i.&#8239;e. you must have double-clicked into it. Now press the @[Ctrl]@ key and move the mouse pointer over the type name. The former changes its shape into a hand symbol and the latter changes into a hyperlink:
+Given a variable definition in a statechart's definition section, you can lookup the corresponding type definition. The definition section must be in editing mode, i.e. you must have double-clicked into it. Now press the @[Ctrl]@ key and move the mouse pointer over the type name. The former changes its shape into a hand symbol and the latter changes into a hyperlink:
 
 !images/cdom_geometry_160_type_lookup_010.png(Looking up a C type)!
 
@@ -463,7 +463,7 @@ typedef struct {
 #endif /* TRIANGLE_H_ */
 
 
-p. Similar to the _Triangle_ type or any other C type, the _Color_ enumeration type can be used in the statechart, e.&#8239;g. by declaring an additional interface variable:
+p. Similar to the _Triangle_ type or any other C type, the _Color_ enumeration type can be used in the statechart, e.g. by declaring an additional interface variable:
 
 bc.. import: color
 import: triangle
@@ -480,7 +480,7 @@ In order to see which values are available the content assist, triggered by @[Ct
 
 p=. Using content assist to select an enumeration value
 
-Once initialized, the _c_ variable can now be used e.&#8239;g. in an assignment to the triangle _t_'s fill color:
+Once initialized, the _c_ variable can now be used e.g. in an assignment to the triangle _t_'s fill color:
 
 bc.  t.fillColor = c;
 
@@ -499,7 +499,7 @@ Let's say our *rectangle.h* header file not only defines the data type, but also
 bc. extern int32_t area(Rectangle r);
 
 For the sake of the example, let's assume the function calculates the area of the given rectangle. Of course we could also do this with means built into the statechart language. However, in the general case you neither _can_ nor _want_ to do that.
-* Implementing the functionality in the statechart language might not be possible, because the latter does not provide the necessary means, e.&#8239;g. to pull some data from an external source.
+* Implementing the functionality in the statechart language might not be possible, because the latter does not provide the necessary means, e.g. to pull some data from an external source.
 * Even if it would be possible to implement the functionality in the statechart language, it might still not be desirable, if the functionality has been developed and fully tested in C already. You will neither want to re-invent the wheel nor would you want to introduce any new errors into an alternative implementation.
 
 YAKINDU Statechart Tools parses function declarations in header files and makes the functions available in the statechart language. It doesn't care where those functions are defined – or whether they are defined at all – nor what they do. Questions like these will become relevant later when the state machine is generated as C source code, compiled and linked to the functions' implementations.
@@ -521,17 +521,17 @@ bq.. *Please note:*
 
 State machines calling C functions as operations are debarred from simulation and debugging. The simulator is not yet capable to call C functions.
 
-h2(#cdom_generating-c-source-code). Generating C source code
+h2(#cdom_generating_c_source_code). Generating C source code
 
-Code generation, i.&#8239;e. turning a statechart model into source code of a programming language, is explained in the section _Generating state machine code_. Therefore we won't go into the details here, but instead only put some emphasis on code generation specialties of the _Deep C Integration_.
+Code generation, i.e. turning a statechart model into source code of a programming language, is explained in the section _Generating state machine code_. Therefore we won't go into the details here, but instead only put some emphasis on code generation specialties of the _Deep C Integration_.
 
-h3(#cdom_creating-a-generator-model). Creating a generator model
+h3(#cdom_creating_a_generator_model). Creating a generator model
 
 In the statechart model introduced above, do the following:
 
 # In the project view, right-click on the project's name. The context menu opens.
 # In the context menu, select _New → Code Generator Model_. The _YAKINDU Generator Model_ wizard opens.
-# Enter a file name into the _File name_ field, e.&#8239;g. *c.sgen*, and click _Next >_.
+# Enter a filename into the _File name_ field, e.g. *c.sgen*, and click _Next >_.
 # In the _Generator_ drop-down menu, select *YAKINDU SCT C Code Generator*.
 # Select the statechart models to generate C source code for. Click _Finish_.
 
@@ -551,7 +551,7 @@ bc.. GeneratorModel for yakindu::c {
 
 p. YAKINDU Statechart Tools creates the target folders _src_ and _src-gen_ and generates the C source representing the statemachine into them.
 
-h3(#cdom_the-generated-c-code). The generated C code
+h3(#cdom_the_generated_c_code). The generated C code
 
 Particularly interesting are the files *Statechart.h* and *Statechart.c*.
 
@@ -594,7 +594,7 @@ static void statechart_enact_main_region_Check(Statechart* handle)
 }
 
 
-h2(#cdom_currently-supported-primitive-types). Currently supported primitive types
+h2(#cdom_currently_supported_primitive_types). Currently supported primitive types
 
 The _Deep C Integration_ natively supports the following primitive C types. That is, in a statechart without any additional data type definitions, the following types are readily available:
 
@@ -613,17 +613,17 @@ The _Deep C Integration_ natively supports the following primitive C types. That
 * _void_
 
 
-h2(#cdom_current-restrictions). Current restrictions
+h2(#cdom_current_restrictions). Current restrictions
 
 The current release candidate of YAKINDU Statechart Tools PRO is still missing some C functionalities that will be approached as soon as possible by subsequent releases. Among others, the following issues are known to be not available yet:
 
-h3(#cdom_current-type-range-checks). Type range checks
+h3(#cdom_current_type_range_checks). Type range checks
 
-Type range validations are currently not implemented. As a consequence, it is possible to e.&#8239;g. assign an _int32_t_ value to an _int8_t_ variable one without any warning.
+Type range validations are currently not implemented. As a consequence, it is possible to e.g. assign an _int32_t_ value to an _int8_t_ variable one without any warning.
 
 ###. CHECK: Are type range validations still not implemented in the C domain?
 
-h3(#cdom_plain-struct-union-and-enum-types). Plain struct, union, and enum types
+h3(#cdom_plain_struct_union_and_enum_types). Plain struct, union, and enum types
 
 In C it is possible to define structs, unions and enums without a _typedef_. They can be referenced by using the corresponding qualifying keyword (_struct_, _union_, or _enum_, respectively). As the statechart language does *not* support these qualifiers, the usage of struct, union and enumeration types is currently restricted to those defined by a _typedef_.
 
@@ -631,7 +631,11 @@ In C it is possible to define structs, unions and enums without a _typedef_. The
 
 
 
-h3(#cdom_please-get-in-touch-with-us). Please get in touch with us
+h3(#cdom_performance_issues_with_very_large_c_projects). Performance issues with very large C projects
+h4(#cdom_processing_header_files_and_macro_definitions). Processing header files and macro definitions
+h4(#cdom_excluding_c_header_files_from_being_parsed). Excluding C header files from being parsed
+h4(#cdom_deactivating_the_ccpp_indexer). Deactivating the C/C++ indexer
+h3(#cdom_please_get_in_touch_with_us). Please get in touch with us
 
 Please note that the preceding list of restrictions might not be complete. If you discover any further problems, please do not hesitate to contact us! Your feedback is highly appreciated!
 

plugins/org.yakindu.sct.doc.user/src/user-guide/sctunit.textile

@@ -1,6 +1,10 @@
 
 p(edit-on-github). "Edit on GitHub":https://github.com/Yakindu/statecharts/edit/master/plugins/org.yakindu.sct.doc.user/src/user-guide/sctunit.textile
 
+
+
+
+
 h1(#sctunit_test-driven_statechart_development_with_sctunit). Test-driven statechart development with SCTUnit
 
 h2(#sctunit_brief_introduction_to_test-driven_development). Brief introduction to test-driven development
@@ -49,7 +53,7 @@ In the _test_ directory, proceed as follows to create a SCTUnit test file:
 # In the context menu, select _New → Other…_. The _New_ wizard opens.
 # In the wizard, select _YAKINDU SCT → SCTUnit test case_.
 # Click _Next >_. The wizard switches to the _New SCTUnit Test Class_ page.
-# In the _File name_ text field, specify the name of the file to contain the SCTUnit tests, say, _light_switch.sctunit_. The file name extension must always be _.sctunit_.
+# In the _Filename_ text field, specify the name of the file to contain the SCTUnit tests, say, _light_switch.sctunit_. The filename extension must always be _.sctunit_.
 # Click _Finish_.
 # If a dialog appears asking whether you want to add the Xtext nature to the project, please click _Yes_.
 
@@ -215,6 +219,7 @@ An important extension of the SCTUnit language over the statechart language is t
 Please remember that you can always hit <code>[Ctrl]+[Space]</code> when editing SCTUnit language files within YAKINDU Statechart Tools. The editor will show you all possible input choices that are valid at your cursor location.
 
 
+
 ==<!-- Start sctunit_keyword_testclass -->==
 
 h3(#sctunit_test_classes). Test classes
@@ -266,6 +271,8 @@ Test classes can be grouped into a "test suite":#sctunit_test_suites.
 
 ==<!-- End sctunit_keyword_testclass -->==
 
+
+
 ==<!-- Start sctunit_keyword_operation -->==
 
 h3(#sctunit_operations_and_tests). Operations and tests
@@ -333,11 +340,13 @@ When running a "test class":#sctunit_test_classes or a "test suite":#sctunit_tes
 
 While the <code>@Ignore</code> annotation and an omitted annotation have the same effect functionally, you should use the <code>@Ignore</code> annotation to mark operations that are intended as tests, but are (temporarily) disabled for one or the other reason. This differentiates them from other operations that are not tests, but mere subroutines called from elsewhere.
 
+
+
 ==<!-- End sctunit_keyword_operation -->==
 
 h3(#sctunit_statements_and_expressions). Statements and expressions
 
-The body of an "operation":#sctunit_operations_and_tests consists of _statements_. Many types of statements, like _variable definitions_, _assignments_, _event raisings_, or _operation calls_, are already defined in the statechart language and are described "in section &quot;Statements&quot; of the statechart language documentation":../user-guide/statechart_language.html#statements.
+The body of an "operation":#sctunit_operations_and_tests consists of _statements_. Many types of statements, like _variable definitions_, _assignments_, _event raisings_, or _operation calls_, are already defined in the statechart language and are described "in section &quot;Statements&quot; of the statechart language documentation":../user-guide/statechart_language#sclang_statements.
 
 Statement types that are specific to the SCTUnit language are described in the following subsections.
 
@@ -369,7 +378,7 @@ The first statement asserts that state _State_A_ in region _main_region_ in stat
 
 The second statement asserts that _State_B_ is not active. Otherwise the test fails with the error message "State_B must not be active here.". 
 
-bq. *Please note:* "active(…)":../user-guide/statechart_language#active-state is a built-in function of the statechart language.
+bq. *Please note:* "active(…)":../user-guide/statechart_language#sclang_active_state is a built-in function of the statechart language.
 
 ==</div>==
 
@@ -411,8 +420,6 @@ p=. Assertion grammar
 ==<!-- End sctunit_keyword_assert -->==
 
 
-
-
 ==<!-- Start sctunit_keyword_enter -->==
 
 h4(#sctunit_entering_a_state_machine). Entering a state machine
@@ -434,7 +441,6 @@ p=. Enter grammar
 ==<!-- End sctunit_keyword_enter -->==
 
 
-
 ==<!-- Start sctunit_keyword_exit -->==
 
 h4(#sctunit_exiting_a_state_machine). Exiting a state machine
@@ -496,7 +502,6 @@ p=. Exit grammar
 ==<!-- End sctunit_keyword_exit -->==
 
 
-
 ==<!-- Start sctunit_keyword_raise -->==
 
 h4(#sctunit_raising_an_event). Raising an event
@@ -526,12 +531,11 @@ This statement raises the _click_ event in the state machine's _user_ interface.
 
 Since state machine internals are inaccessible to SCTUnit tests and outgoing events are, well, outgoing, only incoming events can be raised. Events in the internal scope or outgoing events defined in an interface cannot be raised.
 
-bq. *Please note:* The _raise_ statement is not specific to the SCTUnit language, but is (also) part of the statechart language, see section "&quot;Raising an event&quot;":../user-guide/statechart_language#raising-an-event.
+bq. *Please note:* The _raise_ statement is not specific to the SCTUnit language, but is (also) part of the statechart language, see section "&quot;Raising an event&quot;":../user-guide/statechart_language#sclang_raising_an_event.
 
 ==<!-- End sctunit_keyword_raise -->==
 
 
-
 ==<!-- Start sctunit_keyword_proceed -->==
 
 h4(#sctunit_proceeding_a_state_machine). Proceeding a state machine
@@ -571,12 +575,11 @@ p=. Proceed statement grammar
 ==<!-- End sctunit_keyword_proceed -->==
 
 
-
 ==<!-- Start sctunit_keyword_var -->==
 
 h4(#sctunit_defining_variables_and_constants). Defining variables and constants
 
-Variables and constants (for brevity we'll summarize both as "variables") can be defined as specified in the statechart language, please see sections "&quot;Variables&quot;":../user-guide/statechart_language.html#variables and "&quot;Constants&quot;":../user-guide/statechart_language.html#constants for all the details. 
+Variables and constants (for brevity we'll summarize both as "variables") can be defined as specified in the statechart language, please see sections "&quot;Variables&quot;":../user-guide/statechart_language#sclang_variables and "&quot;Constants&quot;":../user-guide/statechart_language#sclang_constants for all the details. 
 
 However, variables in the SCTUnit language _must_ always be initialized. For example, while a definition like
 
@@ -597,7 +600,6 @@ p=. Variable definition grammar
 ==<!-- End sctunit_keyword_var -->==
 
 
-
 ==<!-- Start sctunit_keyword_if -->==
 ==<!-- Start sctunit_keyword_else -->==
 
@@ -649,7 +651,6 @@ p=. If statement grammar
 ==<!-- End sctunit_keyword_else -->==
 
 
-
 ==<!-- Start sctunit_keyword_while -->==
 
 h4(#sctunit_loops). Loops
@@ -685,6 +686,7 @@ p=. While statement grammar
 
 ==<!-- End sctunit_keyword_while -->==
 
+
 ==<!-- Start sctunit_keyword_is_active -->==
 ==<!-- Start sctunit_keyword_is_final -->==
 
@@ -720,7 +722,6 @@ The assertion fails if the state machine is not active (see above) or it has at
 ==<!-- End sctunit_keyword_is_active -->==
 
 
-
 ==<!-- Start sctunit_keyword_mock -->==
 
 h4(#sctunit_mocking_an_operation_call). Mocking an operation call
@@ -844,7 +845,6 @@ p=. Return statement grammar
 
 
 
-
 h3(#sctunit_test_suites). Test suites
 
 ==<!-- Start sctunit_keyword_testsuite -->==
@@ -886,6 +886,8 @@ Test suites are namespace-aware: Using the "_package_ statement":#sctunit_the_pa
 
 ==<!-- End sctunit_keyword_testsuite -->==
 
+
+
 h3(#sctunit_namespaces). Namespaces
 
 You can organise your "test classes":#sctunit_test_classes and "test suites":#sctunit_test_suites in different namespaces. Each test class or test suite can assign itself to a namespace by the "_package_":#sctunit_the_package_statement statement.
@@ -893,7 +895,6 @@ You can organise your "test classes":#sctunit_test_classes and "test suites":#sc
 ###. CHECK IMPORT: It can import test classes and test suites from other namespaces by the "_import_":#sctunit_the_import_statement statement.
 
 
-
 ==<!-- Start sctunit_keyword_package -->==
 
 h4(#sctunit_the_package_statement). The _package_ statement
@@ -931,7 +932,6 @@ Please see section "&quot;Test units&quot;":#sctunit_test_units for a summary of
 ==<!-- End sctunit_keyword_package -->==
 
 
-
 ###. CHECK IMPORT: ==<!-- Start sctunit_keyword_import -->==
 ###. CHECK IMPORT: 
 ###. CHECK IMPORT: h4(#sctunit_the_import_statement). The _import_ statement
@@ -961,7 +961,6 @@ Please see section "&quot;Test units&quot;":#sctunit_test_units for a summary of
 ###. CHECK IMPORT: ==<!-- End sctunit_keyword_import -->==
 
 
-
 h4(#sctunit_test_units). Test units
 
 A _test unit_ is either a "test class":#sctunit_test_classes or a "test suite":#sctunit_test_suites. It is contained in a file with a _.sctunit_ filename extension.

plugins/org.yakindu.sct.doc.user/toc.xml

@@ -13,10 +13,11 @@
 
     <topic label="User Guide">
         <link toc="help/user-guide/editing_statecharts-toc.xml"/>
-        <link toc="help/user-guide/statechart_language-toc.xml"/>
         <link toc="help/user-guide/simulating_statecharts-toc.xml"/>
         <link toc="help/user-guide/advanced_simulation-toc.xml"/>
         <link toc="help/user-guide/c-domain-toc.xml"/>
+        <link toc="help/user-guide/typescript-domain-toc.xml"/>
+        <link toc="help/user-guide/statechart_language-toc.xml"/>
         <link toc="help/user-guide/generating_code-toc.xml"/>
         <link toc="help/user-guide/generating_code_headless-toc.xml"/>
         <link toc="help/user-guide/sctunit-toc.xml"/>