it makes more sense to block quote the question

1 files changed, 32 insertions, 32 deletions

diff --git a/README.md b/README.md
index 024d864..04b612b 100644
--- a/README.md
+++ b/README.md
@@ -6,38 +6,38 @@ Hermes is interesting as it exposes us to various design problems namely network
 synchronization, scheduling, and GUI design.
 
 ### Analysis
-Will you use data abstraction? How?
-> TCP communication will be abstracted away so will only deal with Hermes
-> definition of a message.
-> We will try to encrypt the messages passed around. The encryption will be
-> abstracted away so we only have to think about it once during implementation
-
-Will you use recursion? How?
-> The  server will continually loop waiting for connections from clients.
-> The Gui will continually loop to handle input with the user, and to and fro
-> Hermes.
-
-Will you use map/filter/reduce? How? 
-> Map will be used for dealing editor area of clients.
-
-Will you use object-orientation? How?
-> Keeping account of the number of clients will require an object of some sort.
-> With procedures to increment and decrement the number of users
-
-Will you use functional approaches to processing your data? How?
-> The communication part of Hermes is over tcp which uses a lot of functional
-> approaches e.g. you start a listener which you can then pass to tcp accept.
-> The result of tcp accept are two pairs of ports which we can then bind to some
-> variables. 
-
-Will you use state-modification approaches? How? (If so, this should be encapsulated within objects. `set!` pretty much should only exist inside an object.)
-> State-modification will be used e.g. keeping count of logged in users requires
-> state modification via set! to maintain the true user account
-
-Will you build an expression evaluator, like we did in the symbolic differentatior and the metacircular evaluator?
-> Users will type their input into a text field from the GUI. We will retrieve
-> the command and evaluate it to see if its a message, or a command to change
-> GUI state. We will do something that resembles the metacircular evaluator.
+> Will you use data abstraction? How?
+TCP communication will be abstracted away so will only deal with Hermes
+definition of a message.
+We will try to encrypt the messages passed around. The encryption will be
+abstracted away so we only have to think about it once during implementation
+
+> Will you use recursion? How?
+The  server will continually loop waiting for connections from clients.
+The Gui will continually loop to handle input with the user, and to and fro
+Hermes.
+
+> Will you use map/filter/reduce? How? 
+Map will be used for dealing editor area of clients.
+
+> Will you use object-orientation? How?
+Keeping account of the number of clients will require an object of some sort.
+With procedures to increment and decrement the number of users
+
+> Will you use functional approaches to processing your data? How?
+The communication part of Hermes is over tcp which uses a lot of functional
+approaches e.g. you start a listener which you can then pass to tcp accept.
+The result of tcp accept are two pairs of ports which we can then bind to some
+variables. 
+
+> Will you use state-modification approaches? How? (If so, this should be encapsulated within objects. `set!` pretty much should only exist inside an object.)
+State-modification will be used e.g. keeping count of logged in users requires
+state modification via set! to maintain the true user account
+
+> Will you build an expression evaluator, like we did in the symbolic differentatior and the metacircular evaluator?
+Users will type their input into a text field from the GUI. We will retrieve
+the command and evaluate it to see if its a message, or a command to change
+GUI state. We will do something that resembles the metacircular evaluator.
 
 
 ### Deliverable and Demonstration