Merge pull request sinatra#262 from baldowl/readme_tweaks.

Readme tweaks

README.rdoc

@@ -494,7 +494,7 @@ Or, specify an explicit Hash of local variables:
 
   get '/:id' do
     foo = Foo.find(params[:id])
-    haml '%h1= foo.name', :locals => { :foo => foo }
+    haml '%h1= bar.name', :locals => { :bar => foo }
   end
 
 This is typically used when rendering templates as partials from within
@@ -653,7 +653,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:
 
@@ -1327,8 +1327,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
 
@@ -1337,8 +1337,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'
 
@@ -1351,15 +1351,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]
@@ -1466,7 +1466,7 @@ application (Rails/Ramaze/Camping/...):
     get('/login') { haml :login }
 
     post('/login') do
-      if params[:name] = 'admin' and params[:password] = 'admin'
+      if 'admin' == params[:name] && 'admin' == params[:password]
         session['user_name'] = params[:name]
       else
         redirect '/login'
@@ -1533,9 +1533,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.