Updated user documentation with anchors added for hovre integration

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

@@ -27,7 +27,10 @@
       <topic href="help/user/05_Reference/reference.html#Transitions" label="Transitions reference"/>
  	     
    </context>
-   <context id="sc_genmodel_features" title="Genmodel Features">
-      <topic href="help/user/04_Tasks/tasks.html" label="Outlet"/>
+   <context id="sgen_feature" title="Genmodel Features">
+      <topic href="help/user/04_Tasks/tasks.html" label="Help_Topic"/>
+   </context>
+   <context id="stext_keyword">
+      <topic href="help/user/05_Reference/reference.html" label="Help_Topic"/>
    </context>
 </contexts>

plugins/org.yakindu.sct.doc.user/help/user/04_Tasks/tasks-toc.xml

@@ -7,15 +7,10 @@
 		<topic href="help/user/04_Tasks/tasks.html#Validatingastatemachine" label="Validating a statemachine"></topic>
 		<topic href="help/user/04_Tasks/tasks.html#Simulatingastatemachine" label="Simulating a statemachine"></topic>
 		<topic href="help/user/04_Tasks/tasks.html#GeneratingCode" label="Generating Code"></topic>
-		<topic href="help/user/04_Tasks/tasks.html#CoreFeatures" label="Core Features">
-			<topic href="help/user/04_Tasks/tasks.html#Outlet" label="Outlet"></topic>
-			<topic href="help/user/04_Tasks/tasks.html#LicenseHeader" label="LicenseHeader"></topic>
-			<topic href="help/user/04_Tasks/tasks.html#FunctionInlining" label="FunctionInlining"></topic>
-		</topic>
+		<topic href="help/user/04_Tasks/tasks.html#CoreFeatures" label="Core Features"></topic>
 		<topic href="help/user/04_Tasks/tasks.html#JavaGeneratorFeatures" label="Java Generator Features">
 			<topic href="help/user/04_Tasks/tasks.html#Naming" label="Naming"></topic>
-			<topic href="help/user/04_Tasks/tasks.html#GeneralFeatures" label="GeneralFeatures
-TBD"></topic>
+			<topic href="help/user/04_Tasks/tasks.html#GeneralFeatures" label="GeneralFeatures"></topic>
 		</topic>
 		<topic href="help/user/04_Tasks/tasks.html#CGeneratorFetures" label="C Generator Fetures
 TBD"></topic>

plugins/org.yakindu.sct.doc.user/help/user/04_Tasks/tasks.textile

@@ -97,6 +97,7 @@ h2. Core Features
 
 The following section describes the *Core Features* which are available for all code generators:
 
+==<!-- Start sgen_feature_outlet -->==
 h4. Outlet
 
 The *Outlet* feature specifies the target project and folder for the generated artifacts. It is a *required* feature and consists of the following parameters:
@@ -110,8 +111,8 @@ feature Outlet {
 	targetProject = "ExampleProject"
 	targetFolder = "src-gen"
 }
-p. ==<!-- End Outlet -->==
-
+p. ==<!-- End sgen_feature_outlet -->==
+==<!-- Start sgen_feature_licenseheader -->==
 h4. LicenseHeader
 
 The *LicenseHeader* feature specifies the license text that should be added as a header to the generated artifacts. It is an *optional* feature and consists of the following parameters:
@@ -124,8 +125,8 @@ bc..
 feature LicenseHeader {
 	licenseText = "Copyright (c) 2012 committers of YAKINDU and others."
 }
-p. ==<!-- End LicenseHeader -->==
-
+p. ==<!-- End sgen_feature_licenseheader -->==
+==<!-- Start sgen_feature_functioninlining -->==
 h4. FunctionInlining
 
 The *FunctionInlining* feature allows the inlining of expressions instead of generating separate functions or methods. This might reduce the readability of the generated code, but increases performance because less operation calls are necessary. 
@@ -149,8 +150,8 @@ feature FunctionInlining {
 	inlineEnterRegion = true
 	inlineEntries = true
 }
-p. ==<!-- End FunctionInlining -->==
-
+p. ==<!-- End sgen_feature_functioninlining -->==
+==<!-- Start sgen_feature_debug -->==
 h4. Debug
 
 The *Debug* feature dumps the Execution Model to the target folder as xmi model. It is an *optional* feature and consists of the following parameters:
@@ -164,10 +165,12 @@ feature Debug {
 	dumpSexec = true
 }
 
-p. ==<!-- End Debug -->==
+p. ==<!-- End sgen_feature_debug -->==
 
 h2. Java Generator Features
 
+==<!-- Start sgen_feature_naming -->==
+
 h4. Naming
 
 The *Naming* feature allows the configuration of package names as well as class name prefix / suffix.
@@ -183,8 +186,8 @@ feature Naming {
 	basePackage = "org.yakindu.sct"
 	implementationSuffix = "Impl"
 }
-p. ==<!-- End Naming -->==	
-
+p. ==<!-- End sgen_feature_naming -->==	
+==<!-- Start sgen_feature_generalfeatures -->==	
 
 h4. GeneralFeatures
 
@@ -209,7 +212,7 @@ feature GeneralFeatures {
 	StatemachineFactorySupport = true
 }
 
-p. ==<!-- End GeneralFeatures -->==			
+p. ==<!-- End sgen_feature_generalfeatures -->==			
 
 h2. C Generator Fetures
 TBD
@@ -235,6 +238,8 @@ h3. Executing a custom Xtend2/Java code generator
 YAKINDU Statechart Tools provide a convenient way to execute your generator while you are developing it.
 Therefore, you have to create a new *Generator Model* with the generator id *yakindu::generic*, either by using the *New Statechart Generator Model* wizard or by simple creating a new text file with the file extension *.sgen*. the following feature allows to configure your code generator.
 
+==<!-- Start sgen_feature_generator -->==
+
 h4. Generator
 
 The *Generator* feature allows the configuration of a custom code generator located in the workspace and written in Java or another JVM language. It is a *required* feature and consists of the following parameters:
@@ -251,7 +256,7 @@ feature Generator {
 	generatorClass = "org.yakindu.sct.MyGenerator"
 }
 		
-p. ==<!-- End Generator -->==
+p. ==<!-- End sgen_feature_generator -->==
 
 
 

plugins/org.yakindu.sct.doc.user/help/user/05_Reference/reference.html

@@ -224,10 +224,15 @@ event checkValidity : boolean
 		</p>
 		<p>An operation is called similar to other programming languages with the operation name and passing concrete parameters. The parameters can be expressions.</p>
 		<h3 id="Scopes">Scopes</h3>
+		<p><!-- Start stext_keyword_namespace --></p>
 		<h4 id="Namespace">Namespace</h4>
 		<p>The language allows to define unique namespaces, which can be used to qualify references to the statechart.</p>
 		<pre><code>namespace trafficlights
+
 </code></pre>
+		<p><!-- End stext_keyword_namespace -->
+			<br/><!-- Start stext_keyword_interface -->
+		</p>
 		<h4 id="interfacescope">interface scope</h4>
 		<p>Declarations in the interface scope are externally visible. They can be shared within the environment.</p>
 		<pre><code>interface NamedInterface:
@@ -236,7 +241,11 @@ out event event3
 var variable1 : real
 entrypoint entry1
 exitpoint exit1
+
 </code></pre>
+		<p><!-- End stext_keyword_interface -->
+			<br/><!-- Start stext_keyword_internal -->
+		</p>
 		<h4 id="internalscope">internal scope</h4>
 		<p>Declarations made in an internal scope are only visible for contained states.</p>
 		<pre><code>internal:
@@ -247,9 +256,12 @@ local event localEvent3: localEvent || localEvent2 : 25
 operation localOperation (integer, integer): integer
 localEvent3 / raise NamedInterface.event3 :
 localOperation(valueOf(localEvent),NamedInterface.variable1);
+
 </code></pre>
+		<p><!-- End stext_keyword_internal --></p>
 		<h3 id="Declarations">Declarations</h3>
 		<p>Within scopes there can be declarations of Events, Variables, Operations, LocalReactions, EntryPoints and ExitPoints.</p>
+		<p><!-- Start stext_keyword_event --></p>
 		<h3 id="Events">Events</h3>
 		<p>Within interface scope events have an direction. They can either be ingoing or outgoing:</p>
 		<pre><code>interface NamedInterface:
@@ -265,7 +277,10 @@ event localEvent1 : integer
 event localEvent1: integer
 local event localEvent2 = NamedInterface.event1 || localEvent1
 local event localEvent3 = localEvent2 || 25
+
 </code></pre>
+		<p><!-- End stext_keyword_event --></p>
+		<p><!-- Start stext_keyword_var --></p>
 		<h3 id="Variables">Variables</h3>
 		<p>Variables can have different visibilities. They can be visible for the environment:</p>
 		<pre><code>var variable1: real
@@ -277,9 +292,12 @@ local event localEvent3 = localEvent2 || 25
 </code></pre>
 		<p>Variables can be referenced by the environment.</p>
 		<pre><code>var external variable3: integer = 34
+
 </code></pre>
+		<p><!-- End stext_keyword_var --></p>
 		<h3 id="Actions">Actions</h3>
 		<p>Actions are key constructs in state machines to model behavior. The YAKINDU SCT 2 knows the following kinds of actions.</p>
+		<p><!-- Start stext_keyword_after --></p>
 		<h4 id="after">after</h4>
 		<p>With the keyword 
 			<em>after</em> you can model a transition after a certain period of time:
@@ -288,34 +306,61 @@ local event localEvent3 = localEvent2 || 25
 after 345mics
 after 4050ns
 after 1234ms
+
 </code></pre>
+		<p><!-- End stext_keyword_after -->
+			<br/><!-- Start stext_keyword_always -->
+		</p>
 		<h4 id="always">always</h4>
 		<p>The keyword always is used only for local reactions that are executed always.</p>
+		<p><!-- End stext_keyword_always -->
+			<br/><!-- Start stext_keyword_default -->
+		</p>
 		<h4 id="default">default</h4>
 		<p>The keyword default marks transitions that are always accomplished.</p>
+		<p><!-- End stext_keyword_else -->
+			<br/><!-- Start stext_keyword_else -->
+		</p>
 		<h4 id="else">else</h4>
 		<p>The keyword 
 			<em>else</em> marks transitions that are carried out in case of a condition. ???
 		</p>
+		<p><!-- End stext_keyword_else -->
+			<br/><!-- Start stext_keyword_entry -->
+		</p>
 		<h4 id="entry">entry</h4>
 		<p>The keyword entry marks actions that are carried out on entering a state.</p>
+		<p><!-- End stext_keyword_entry -->
+			<br/><!-- Start stext_keyword_every -->
+		</p>
 		<h4 id="every">every</h4>
 		<p>
 			<em>Every</em> marks a periodic transition.
 		</p>
+		<p><!-- End stext_keyword_every -->
+			<br/><!-- Start stext_keyword_exit -->
+		</p>
 		<h4 id="exit">exit</h4>
 		<p>
 			<em>Exit</em> marks actions on leaving a state.
 		</p>
+		<p><!-- End stext_keyword_exit -->
+			<br/><!-- Start stext_keyword_oncycle -->
+		</p>
 		<h4 id="onCycle">onCycle</h4>
 		<p>
 			<em>OnCycle</em> marks actions that are carried out.
 		</p>
+		<p><!-- End stext_keyword_oncycle -->
+			<br/><!-- Start stext_keyword_operation -->
+		</p>
 		<h3 id="Operations">Operations</h3>
 		<p>Operations can have none, one or multiple parameters. The parameters are only declarated by their type. An operation can have one return type similar to Java.</p>
 		<pre><code>operation localOperation (integer, integer):integer
 localEvent3/ raise NamedInterface3.event1
+
 </code></pre>
+		<p><!-- End stext_keyword_operation --></p>
 		<h3 id="LocalReactions">LocalReactions</h3>
 		<p>Local reactions describe the internal behavior of a state. So they have internal scope. A local reaction is  declared as follows:</p>
 		<pre><code>LocalReaction: ReactionTrigger '/' ReactionEffect ('#' ReactionProperties)?
@@ -335,15 +380,22 @@ localEvent1 / raise NamedInterface.event3 : localOperation (valueOf(localEvent),
 		<p>Local reactions can have priority values. These are defined by a following # and the integer number of priority:</p>
 		<pre><code>localEvent2 / NamedInterface.variable2 += 3; #1
 localEvent3 / NamedInterface.variable4 += 2.0; #2
+
 </code></pre>
+		<p><!-- Start stext_keyword_entrypoint --></p>
 		<h3 id="EntryPoints">EntryPoints</h3>
 		<p>Every state chart has an entry point. An entry point can be declared like the following:</p>
 		<pre><code>entrypoint entry1
+
 </code></pre>
+		<p><!-- End stext_keyword_entrypoint -->
+			<br/><!-- Start stext_keyword_exitpoint -->
+		</p>
 		<h3 id="ExitPoints">ExitPoints</h3>
 		<p>Every state chart has an exit point. This exit point can be declared like the following.</p>
 		<pre><code>exitpoint exit1
 </code></pre>
+		<p><!-- End stext_keyword_exitpoint --></p>
 		<h2 id="SGraph">SGraph</h2>
 		<p>SGraph is the metamodel for the graphical part of the statechart editor. It owns all core elements of a state machine like states, pseudostates, transitons etc. but it describes how these elements shall be shown by the editor.</p>
 		<h2 id="SExec">SExec</h2>

plugins/org.yakindu.sct.doc.user/help/user/05_Reference/reference.textile

@@ -93,7 +93,6 @@ h2. Statechart description language
 
 The textual description language is used to declare and describe behaviors in the state machine. It is case sensitive.
 
-
 h3. Typesystem
 
 The language has an integrated small typesystem with the following simple types:
@@ -198,13 +197,18 @@ An operation is called similar to other programming languages with the operation
 
 h3. Scopes
 
+==<!-- Start stext_keyword_namespace -->==
+
 h4. Namespace
 
 The language allows to define unique namespaces, which can be used to qualify references to the statechart.
 
-
 bc.. 
 namespace trafficlights
+
+p. ==<!-- End stext_keyword_namespace -->==
+==<!-- Start stext_keyword_interface -->==
+
 h4. interface scope
 
 Declarations in the interface scope are externally visible. They can be shared within the environment.
@@ -217,6 +221,10 @@ out event event3
 var variable1 : real
 entrypoint entry1
 exitpoint exit1
+
+p. ==<!-- End stext_keyword_interface -->==
+==<!-- Start stext_keyword_internal -->==
+
 h4. internal scope
 
 Declarations made in an internal scope are only visible for contained states.
@@ -230,11 +238,14 @@ local event localEvent3: localEvent || localEvent2 : 25
 operation localOperation (integer, integer): integer
 localEvent3 / raise NamedInterface.event3 :
 localOperation(valueOf(localEvent),NamedInterface.variable1);
+
+p. ==<!-- End stext_keyword_internal -->==
+
 h3. Declarations
 
 Within scopes there can be declarations of Events, Variables, Operations, LocalReactions, EntryPoints and ExitPoints.
 
-
+==<!-- Start stext_keyword_event -->==
 
 h3. Events
 
@@ -256,6 +267,11 @@ internal:
 event localEvent1: integer
 local event localEvent2 = NamedInterface.event1 || localEvent1
 local event localEvent3 = localEvent2 || 25
+
+p. ==<!-- End stext_keyword_event -->==
+
+==<!-- Start stext_keyword_var -->==
+
 h3. Variables
 
 Variables can have different visibilities. They can be visible for the environment:
@@ -270,10 +286,15 @@ p. Variables can be referenced by the environment.
 
 bc.. 
 var external variable3: integer = 34
+
+p. ==<!-- End stext_keyword_var -->==
+
 h3. Actions
 
 Actions are key constructs in state machines to model behavior. The YAKINDU SCT 2 knows the following kinds of actions.
 
+==<!-- Start stext_keyword_after -->==
+
 h4. after
 
 With the keyword _after_ you can model a transition after a certain period of time:
@@ -283,34 +304,59 @@ after 1s
 after 345mics
 after 4050ns
 after 1234ms
+
+p. ==<!-- End stext_keyword_after -->==
+==<!-- Start stext_keyword_always -->==
+
 h4. always
 
 The keyword always is used only for local reactions that are executed always.
 
+==<!-- End stext_keyword_always -->==
+==<!-- Start stext_keyword_default -->==
+
 h4. default
 
 The keyword default marks transitions that are always accomplished.
 
+==<!-- End stext_keyword_else -->==
+==<!-- Start stext_keyword_else -->==
+
 h4. else
 
 The keyword _else_ marks transitions that are carried out in case of a condition. ???
 
+==<!-- End stext_keyword_else -->==
+==<!-- Start stext_keyword_entry -->==
+
 h4. entry
 
 The keyword entry marks actions that are carried out on entering a state.
 
+==<!-- End stext_keyword_entry -->==
+==<!-- Start stext_keyword_every -->==
+
 h4. every
 
 _Every_ marks a periodic transition.
 
+==<!-- End stext_keyword_every -->==
+==<!-- Start stext_keyword_exit -->==
+
 h4. exit
 
 _Exit_ marks actions on leaving a state.
 
+==<!-- End stext_keyword_exit -->==
+==<!-- Start stext_keyword_oncycle -->==
+
 h4. onCycle
 
 _OnCycle_ marks actions that are carried out.
 
+==<!-- End stext_keyword_oncycle -->==
+==<!-- Start stext_keyword_operation -->==
+
 h3. Operations
 
 Operations can have none, one or multiple parameters. The parameters are only declarated by their type. An operation can have one return type similar to Java.
@@ -318,6 +364,9 @@ Operations can have none, one or multiple parameters. The parameters are only de
 bc.. 
 operation localOperation (integer, integer):integer
 localEvent3/ raise NamedInterface3.event1
+
+p. ==<!-- End stext_keyword_operation -->==
+
 h3. LocalReactions
 
 Local reactions describe the internal behavior of a state. So they have internal scope. A local reaction is  declared as follows:
@@ -342,18 +391,27 @@ p. Local reactions can have priority values. These are defined by a following #
 bc.. 
 localEvent2 / NamedInterface.variable2 += 3; #1
 localEvent3 / NamedInterface.variable4 += 2.0; #2
+
+p. ==<!-- Start stext_keyword_entrypoint -->==
+
 h3. EntryPoints
 
 Every state chart has an entry point. An entry point can be declared like the following:
 
 bc.. 
 entrypoint entry1
+
+p. ==<!-- End stext_keyword_entrypoint -->==
+==<!-- Start stext_keyword_exitpoint -->==
+
 h3. ExitPoints
 
 Every state chart has an exit point. This exit point can be declared like the following.
 
 bc.. 
 exitpoint exit1
+p. ==<!-- End stext_keyword_exitpoint -->==
+
 h2. SGraph
 
 SGraph is the metamodel for the graphical part of the statechart editor. It owns all core elements of a state machine like states, pseudostates, transitons etc. but it describes how these elements shall be shown by the editor.