README markup tweaks.

README.rdoc

@@ -785,7 +785,7 @@ session hash per user session:
 
 Note that <tt>enable :sessions</tt> actually stores all data in a cookie. This
 might not always be what you want (storing lots of data will increase your
-traffic, for instance). You can use any Rack session middleware, in order to
+traffic, for instance). You can use any Rack session middleware: in order to
 do so, do *not* call <tt>enable :sessions</tt>, but instead pull in your
 middleware of choice how you would any other middleware:
 
@@ -1427,8 +1427,8 @@ recommended:
     end
   end
 
-NOTE: The built-in Sinatra::Test module and Sinatra::TestHarness class
-are deprecated as of the 0.9.2 release.
+NOTE: The built-in <tt>Sinatra::Test</tt> module and
+<tt>Sinatra::TestHarness</tt> class are deprecated as of the 0.9.2 release.
 
 == Sinatra::Base - Middleware, Libraries, and Modular Apps
 
@@ -1437,8 +1437,8 @@ considerable drawbacks when building reusable components such as Rack
 middleware, Rails metal, simple libraries with a server component, or
 even Sinatra extensions. The top-level DSL pollutes the Object namespace
 and assumes a micro-app style configuration (e.g., a single application
-file, ./public and ./views directories, logging, exception detail page,
-etc.). That's where Sinatra::Base comes into play:
+file, <tt>./public</tt> and <tt>./views</tt> directories, logging, exception
+detail page, etc.). That's where <tt>Sinatra::Base</tt> comes into play:
 
   require 'sinatra/base'
 
@@ -1451,15 +1451,15 @@ etc.). That's where Sinatra::Base comes into play:
     end
   end
 
-The methods available to Sinatra::Base subclasses are exactly as those
+The methods available to <tt>Sinatra::Base</tt> subclasses are exactly as those
 available via the top-level DSL. Most top-level apps can be converted to
-Sinatra::Base components with two modifications:
+<tt>Sinatra::Base</tt> components with two modifications:
 
 * Your file should require <tt>sinatra/base</tt> instead of +sinatra+;
   otherwise, all of Sinatra's DSL methods are imported into the main
   namespace.
 * Put your app's routes, error handlers, filters, and options in a subclass
-  of Sinatra::Base.
+  of <tt>Sinatra::Base</tt>.
 
 <tt>Sinatra::Base</tt> is a blank slate. Most options are disabled by default,
 including the built-in server. See {Options and Configuration}[http://sinatra.github.com/configuration.html]
@@ -1632,9 +1632,9 @@ available.
 
 === Application/Class Scope
 
-Every Sinatra application corresponds to a subclass of Sinatra::Base. If you
+Every Sinatra application corresponds to a subclass of <tt>Sinatra::Base</tt>. If you
 are using the top-level DSL (<tt>require 'sinatra'</tt>), then this class is
-Sinatra::Application, otherwise it is the subclass you created explicitly. At
+<tt>Sinatra::Application</tt>, otherwise it is the subclass you created explicitly. At
 class level you have methods like +get+ or +before+, but you cannot access the
 +request+ object or the +session+, as there only is a single application class
 for all requests.