TheTheoryOfCode · karzhenkov · Apr 1, 2020 · Apr 1, 2020 · Apr 1, 2020 · Apr 1, 2020
diff --git a/Chapter-2/Readme.md b/Chapter-2/Readme.md
@@ -148,7 +148,7 @@ int main() {
 
 ### 2.2.2 : Creating Manual EVENT-HANDLERS
 
-_Manual "EVENT-HANDLERS" are the places where the real code for the statemachine will be written by developers._ __Boost::statechart__ _provides a framework to write custom event handlers. Custom events are declared using_ __sc::customer_Reaction__ _and these custom handler functions are named as_ __react__ _and will always return_ __sc::result__. _It takes the const Event reference as a parameter. The signature of the react function is fixed and can't be changed. Let's convert the above example to transiting the class using custom handlers._
+_Manual "EVENT-HANDLERS" are the places where the real code for the statemachine will be written by developers._ __Boost::statechart__ _provides a framework to write custom event handlers. Custom events are declared using_ __sc::custom_reaction__ _and these custom handler functions are named as_ __react__ _and will always return_ __sc::result__. _It takes the const Event reference as a parameter. The signature of the react function is fixed and can't be changed. Let's convert the above example to transiting the class using custom handlers._
 
 ```
 struct firstState;
@@ -191,7 +191,7 @@ sc::result react(const event_MoveToSecondState &event) {
 
 #### 2.2.2.1 : Creating Multiple Manual EVENT-HANDLERS
 
-_Similar to automated event handlers, we can have multiple manual event handlers using_ __mpl::list__. _We do need to write separate __react__ _functions for each event type. Let's reqrite the 2 event handler, one moves to_ __secondState__ _and other moves to_ __thirdState__.
+_Similar to automated event handlers, we can have multiple manual event handlers using_ __mpl::list__. _We do need to write separate_ __react__ _functions for each event type. Let's require two event handlers, one moves to_ __secondState__ _and other moves to_ __thirdState__.
 
 ```
 

diff --git a/Chapter-4/Readme.md b/Chapter-4/Readme.md
@@ -33,7 +33,7 @@ _As earlier, we need to specify the starting state while creating the state mach
 struct statemachine : sc::state_machine<statemachine, firstState> {};
 
 ```
-_Now, the create Meta State, we need to also specify the starting state of the_ __firstState__. _This is done by providing a 3rd parameter while creating the state._
+_Now, to create Meta State, we need to also specify the starting state of the_ __firstState__. _This is done by providing a 3rd parameter while creating the state._
 
 ```
 struct firstState : sc::simple_state<firstState, statemachine, firstState_Inner_1> {};
@@ -48,7 +48,7 @@ struct firstState_Inner_1 : sc::simple_state<firstState_Inner_1, firstState> {
 	firstState_Inner_1() { cout << "In State => firstState_Inner_1" << endl; }
 };
 ```
-_The only difference between a normal state and the meta state is that the normal state takes_ __statemachine__ _as a 2nd template parameter while meta state takes_ __Meta State__ _as 2nd template parameter. The stetemachine code once stated will be in in_ __firstState_Inner_1__.
+_The only difference between a normal state and the meta state is that the normal state takes_ __statemachine__ _as a 2nd template parameter while meta state takes_ __Meta State__ _as 2nd template parameter. The statemachine code once started will be in in_ __firstState_Inner_1__.
 
 ## 4.2  State Transition inside Meta States
 
@@ -111,7 +111,7 @@ _In the above example, we handled the event in Inner States of the Meta State. T
 struct firstState : sc::simple_state<firstState, statemachine, firstState_Inner_1> {
 	typedef sc::custom_reaction<event_Inner1_Inner2> reactions;
 	sc::result react(const event_Inner1_Inner2 & event) {
-		return treturn discard_event();;
+		return discard_event();
 	}
 };
 
@@ -229,5 +229,5 @@ int main() {
 
 ```
 ## 4.3 Conclusion
-_In this chapter, we learned how to create a_ __Meta State__ _which can have multiple inner states with its own event handlers. We have also seen that states can move from inter state to outer state and vice versa in response to an event._
+_In this chapter, we learned how to create a_ __Meta State__ _which can have multiple inner states with its own event handlers. We have also seen that states can move from inner state to outer state and vice versa in response to an event._
 
diff --git a/Chapter-5/Readme.md b/Chapter-5/Readme.md
@@ -164,7 +164,7 @@ _The statement sounds complicated, but will make more sense with upcoming exampl
 
 ### 5.3.1 : Adding a thirdState
 
-_In the example above, if we handle only event_ __event_OutOfBlueEvent__ _in_ __secondState__ _then what will happen to the event_ __event_OutOfGreenEvent__ _which was_ __deferred__ _in firstState. Furthermore, if we move to a_ __thirdState__ _as a result of event_ __event_OutOfBlueEvent__, _then the deferred state will persist for_ __thirdState__
+_In the example above, if we handle only event_ __event_OutOfBlueEvent__ _in_ __secondState__ _then what will happen to the event_ __event_OutOfGreenEvent__ _which was_ __deferred__ _in firstState. Furthermore, if we move to a_ __thirdState__ _as a result of event_ __event_OutOfBlueEvent__, _then the deferred event will persist for_ __thirdState__
 
 _Lets add a_ __thirdState__ _and a handler for event_ __event_OutOfGreenEvent__
 
@@ -187,9 +187,9 @@ _______________________________________________
 |             event_OutOfGreenEvent           |  
 -----------------------------------------------
 ```
-_At_ __thirdState__, _the event_ __event_OutOfGreenEvent__ _is handled as it was maintained in the deferred queue.
+_At_ __thirdState__, _the event_ __event_OutOfGreenEvent__ _is handled as it was maintained in the deferred queue_.
 
-Unfortunately, things get changed if we change the sequence of posting events. if we post_ __event_OutOfGreenEvent__ _before_ __event_OutOfBlueEvent__ _then_ __event_OutOfGreenEvent__ _remains unhandled_
+_Unfortunately, things get changed if we change the sequence of posting events. If we post_ __event_OutOfGreenEvent__ _before_ __event_OutOfBlueEvent__ _then_ __event_OutOfGreenEvent__ _remains unhandled_
 
 _Let's see how event queues  plays a role in it. First, we'll amend the sequence of posting events_
 

diff --git a/Chapter-6/Readme.md b/Chapter-6/Readme.md
@@ -2,9 +2,9 @@
 
 _As we saw in_ __[chapter - 4 : Working with Meta States](https://github.com/9lean/State-Machine-Using-Boost-Statechart/tree/master/Chapter-4)__, _if an event is  unhandled in_ __Inner State__, _it gets automatically propagated to_ __Outer State__. _Which means all unhandled states can be handled in_ __Outer State__.
 
-_This is good unless we come to a situation where we want only certain events to be propagated to_ __Outer State__ _because we want to do something as part of this event handling in_ __Inner State__ _as well as in__ __Outer state__
+_This is good unless we come to a situation where we want only certain events to be propagated to_ __Outer State__ _because we want to do something as part of this event handling in_ __Inner State__ _as well as in_ __Outer state__
 
-_We can use_ __forward_even()__ _for these situations
+_We can use_ __forward_even()__ _for these situations_
 
 
 ## 6.1  Using forward_event

diff --git a/README.md b/README.md
@@ -6,7 +6,7 @@ This mini eBook provides a step by step guide on using Boost::statechart (part o
 
 A large amount of code can potentially be written in the form of state machines. Sometimes even basic switch-case statements are a representation of miniature states. Many a time programmers create multiple states in the code without being explicitly aware of the fact that they are trying to emulate state machines.
 
-__Why should one use exiting state machine framework instead of creating its own?__
+__Why should one use existing state machine framework instead of creating its own?__
 
 Creating a proper state machine require lots of code and should behave as expected in most of the unpredictable scenarios. One may try it out, but it will take a hell lot of development and testing time, which instead could be used for coding the functionality.