Use <tt> tags instead of + signs in README

README.rdoc

@@ -29,19 +29,19 @@ Let's say we're modeling article submission from journalists. An article is writ
 
 Much better, isn't it!
 
-The initial state is +:new+ – in this example that's somewhat meaningless. (?) However, the +:submit+ event <tt>:transitions_to => :being_reviewed</tt>. So, lets instantiate an instance of this Workflow:
+The initial state is <tt>:new</tt> – in this example that's somewhat meaningless. (?) However, the <tt>:submit</tt> event <tt>:transitions_to => :being_reviewed</tt>. So, lets instantiate an instance of this Workflow:
 
   workflow = Workflow.new('Article Workflow')
   workflow.state # => :new
 
-Now we can call the submit event, which transitions to the +:awaiting_review+ state:
+Now we can call the submit event, which transitions to the <tt>:awaiting_review</tt> state:
 
   workflow.submit
   workflow.state # => :awaiting_review
 
 Events are actually instance methods on a workflow, and depending on the state you're in, you'll have a different set of events used to transition to other states.
 
-Given this workflow is now :awaiting_approval, we have a :review event, that we call when someone begins to review the article, which puts the workflow into the +:being_reviewed+ state.
+Given this workflow is now <tt>:awaiting_approval</tt>, we have a <tt>:review</tt> event, that we call when someone begins to review the article, which puts the workflow into the <tt>:being_reviewed</tt> state.
 
 States can also be queried via predicates for convenience like so:
 
@@ -52,9 +52,9 @@ States can also be queried via predicates for convenience like so:
   workflow.new?             # => false
   workflow.awaiting_review? # => true  
 
-Lets say that the business rule is that only one person can review an article at a time – having a state +:being_reviewed+ allows for doing things like checking which articles are being reviewed, and being able to select from a pool of articles that are awaiting review, etc. (rewrite?)
+Lets say that the business rule is that only one person can review an article at a time – having a state <tt>:being_reviewed</tt> allows for doing things like checking which articles are being reviewed, and being able to select from a pool of articles that are awaiting review, etc. (rewrite?)
 
-Now lets say another business rule is that we need to keep track of who is currently reviewing what, how do we do this? We'll now introduce the concept of an action by rewriting our +:review+ event.
+Now lets say another business rule is that we need to keep track of who is currently reviewing what, how do we do this? We'll now introduce the concept of an action by rewriting our <tt>:review</tt> event.
 
   event :review, :transitions_to => :being_reviewed do |reviewer|
     # store the reviewer somewhere for later
@@ -95,17 +95,17 @@ Billy Bob the Manager comes to you and says "I need to know EVERYTHING THAT HAPP
 
 Workflow doesn't try to tell you how to store your log messages, (but we'd suggest using a *splat and storing that somewhere, and keep your log messages flexible).
 
-Finite state machines have the concept of a guard. The idea is that if a certain set of arbitrary conditions are not fulfilled, it will halt the transition from one state to another. We haven't really figured out how to do this, and we don't like the idea of going <tt>:guard => Proc.new {}</tt>, coz that's a bit lame, so instead we have +halt!+
+Finite state machines have the concept of a guard. The idea is that if a certain set of arbitrary conditions are not fulfilled, it will halt the transition from one state to another. We haven't really figured out how to do this, and we don't like the idea of going <tt>:guard => Proc.new {}</tt>, coz that's a bit lame, so instead we have <tt>halt!</tt>
 
-The +halt!+ method is the implementation of the guard concept. Let's take a look.
+The <tt>halt!</tt> method is the implementation of the guard concept. Let's take a look.
 
   state :being_reviewed do
     event :accept, :transitions_to => :accepted do
       halt if true # does not transition to :accepted
     end
   end
 
-Inline with how ActiveRecord does things, +halt!+ also can be called via +halt+, which makes the event return false, so you can trap it with if workflow.event instead of using a rescue block. Using halt returns false.
+Inline with how ActiveRecord does things, <tt>halt!</tt> also can be called via <tt>halt</tt>, which makes the event return false, so you can trap it with if workflow.event instead of using a rescue block. Using halt returns false.
 
   # using halt
   workflow.state   # => :being_reviewed
@@ -123,15 +123,15 @@ Inline with how ActiveRecord does things, +halt!+ also can be called via +halt+,
   workflow.halted? # => true
   workflow.state   # => :being_reviewed
 
-Furthermore, +halt!+ and +halt+ accept an argument, which is the message why the workflow was halted.
+Furthermore, <tt>halt!</tt> and <tt>halt</tt> accept an argument, which is the message why the workflow was halted.
 
   state :being_reviewed do
     event :accept, :transitions_to => :accepted do
       halt 'coz I said so!' if true # does not transition to :accepted
     end
   end
 
-And the API for, like, getting this message, with both +halt+ and +halt!+:
+And the API for, like, getting this message, with both <tt>halt</tt> and <tt>halt!</tt>:
 
   # using halt
   workflow.state          # => :being_reviewed