LOG_RULES.md in u3d-0.9.1 vs LOG_RULES.md in u3d-0.9.2

@@ -25,11 +25,11 @@
 As Unity usually goes through different phases during running, compilation or whichever action you want it to perform, the information (and its processing) that it will output will most likely be dependent on the action being performed.
 Therefore, our log prettifier behaves in a phased fashion. It has an inner memory keeping track of the active 'phase' Unity is going through, the ruleset it applies depends on it.
 
 A phase is started when a given pattern is encountered in the logs, and ends in two different ways: either a terminating pattern is met, or another phase starts.
 
-Because there are rules that you may want to apply throughout the whole analysis, there is a peculiar phase: the 'GENERAL' one. It contains a generic set of rules which will be applied in parallel to the active phase's ruleset, and allows for not having to repeat rules in different phases. The main use which this phase was designed for is to catch exceptions, warnings and errors no matter the active phase, but it is obviously not limited to that.
+Because there are rules that you may want to apply throughout the whole analysis, there is a peculiar phase: the 'GENERAL' one. It contains a generic set of rules which will be applied in parallel to the active phase's ruleset, and allows for not having to repeat rules in different phases. The main use which this phase was designed for is exceptions catching, warnings and errors no matter the active phase, but it is obviously not limited to that.
 
 ### B - Phase syntax
 
 The syntax of phases is as follows:
 
@@ -51,19 +51,19 @@
 * __[OPTIONAL]__ `comment`: short description of the phase. This section is only for readability purpose and will be ignored during parsing as it does not contain logic.
 * `phase_start_pattern`: this is a mandatory pattern that controls the condition under which the phase will start.
 * __[OPTIONAL]__ `phase_end_pattern`: this patterns specifies when the phase should end. It is optional because a phase will also end when another one begins, as stated in II A. This is used when you know exactly when the phase has finished.
 * `rules`: contains a set of rules. See III for further information on rule declaration.
 
-## Rules
+## III - Rules
 
 ### A - Rule declaration
 
 The information contained in Unity's log can be formatted differently: it can be contained in a single line, spread on several, the lines can contain exactly what you want or be way too verbose for your liking.
 
-In consequence, the rule syntax is pretty loose to cover as many cases as possible, and below is describe syntax for some of archetypal rules.
+In consequence, the rule syntax is pretty loose to cover as many cases as possible, and below is describe syntax for some archetypal rules.
 
-They contain nonetheless two mandatory sections and a recurring one:
+They contain nonetheless two mandatory sections:
 
 ```json
 "rule_name": {
   "active": true,
   "start_pattern": "This pattern will start the rule"
@@ -84,10 +84,11 @@
 This example rule extracts the line stating whether the asset database has successfully loaded, and the time and logs it as is.
 
 ### C - One line parsing with data extraction
 
 When the line formatting does not suit your needs, you may want to process it rather than simply logging it. Here is an example which occurs at the beginning of the compile phase:
+
 ```json
 "target": {
   "active": true,
   "start_pattern": "- starting compile (?<path>.+), for buildtarget (?<target>.+)",
   "start_message": "Target: %{path} (buildtarget %{target})"
@@ -95,24 +96,26 @@
 ```
 Simple rewording of the base log, by extracting the meaningful information and putting it back where it was needed.
 
 ### D - Multi-line parsing and displaying
 
-The following rule illustrates when you want to log a chunk of lines as they appear in Unity at the same time. This structure is useful when you know exactly where the block begins and end. If not, please check section F.
+The following rule illustrates when you want to log a chunk of lines as they appear in Unity at the same time. This structure is useful when you know exactly where the block begins and ends. If not, please check section F.
+
 ```json
 "percentage": {
   "active": true,
   "start_pattern": "Textures\\s+\\d+\\.?\\d* .b\\s+\\d{1,3}\\.?\\d*%",
   "end_pattern": "Complete size\\s+\\d+\\.?\\d* .b\\s+\\d{1,3}\\.?\\d*%",
   "store_lines": true
 }
 ```
-`start_pattern` and `end_pattern` are the limits in between which the lines will be parsed. `store_lines` indicates that we want these lines stored, and displayed later.
+`start_pattern` and `end_pattern` are the limits in between which the lines will be parsed. `store_lines` indicates that we want these lines stored, and displayed later on.
 
 ###  E - Multi-line parsing and displaying with line filtering and data extraction
 
 This example illustrates several additional functionalities in comparison to the previous sections.
+
 ```json
 "fail": {
   "active": true,
   "start_pattern": "^(?<fail>Failed to .+)\\n",
   "end_pattern": "Filename: (?:[\\w/:]+/(?<file>\\w+\\.\\w+))? Line: (?<line>-?\\d+)",
@@ -132,11 +135,12 @@
 
 _Note_: this is a modified version of the actual rule, for example purposes.
 
 ### F - Multi-line with no clear entry point (memory fetching)
 
-This section illustrates how a rule will fetch lines from the previously logged lines. It is used when you want to log several lines, but the fixed point is not at the beginning of the block.
+This section illustrates how a rule will fetch lines from the previously logged lines. It is used when you want to log several lines, but the fixed 'entry point' is not at the beginning of the block.
+
 ```json
 "log": {
   "active": true,
   "start_pattern": "UnityEngine\\.Debug:Log\\(Object\\)",
   "fetch_first_line_not_matching": [
@@ -155,16 +159,17 @@
 This previous rule is used to keep tracks of the Debug.Log messages. Because they log the messages first and you probably don't know it or don't want to create a specific rule for every single message, backtracking is necessary. As the full stack isn't necessary either, the `store_lines` is absent (default is `false`) so the full stack is not displayed.
 
 ### G - Logging color code
 
 You can specify the color of the message created by your rules by specifying a type:
+
 ```json
 "target": {
   "active": true,
   "type": "warning"
 }
 ```
 It will output it differently based on this type. Correct types are:
-* __[DEFAULT]__ `message`: normal logging
+* `message`: normal logging __[DEFAULT]__ 
 * `warning`: yellow
-* `error`: red
+* `error`  : red
 * `success`: green