minor fixes and edits [ci skip]

guides/source/action_mailer_basics.textile

@@ -412,18 +412,15 @@ The above will send a multipart email with an attachment, properly nested with t
 
 h5. Sending Emails with Dynamic Delivery Options
 
-At times you may wish to override the default delivery options (e.g. smtp credentials) while delivering emails. This can be achieved using +delivey_method_options+ in the mailer action.
+If you wish to override the default delivery options (e.g. SMTP credentials) while delivering emails, you can do this using +delivery_method_options+ in the mailer action.
 
 <ruby>
 class UserMailer < ActionMailer::Base
   def welcome_email(user,company)
     @user = user
     @url  = user_url(@user)
-    mail(:to => user.email,
-         :subject => "Please see the Terms and Conditions attached",
-         :delivery_method_options => {:user_name => company.smtp_user,
-                                      :password => company.smtp_password,
-                                      :address => company.smtp_host})
+    delivery_options = { user_name: company.smtp_user, password: company.smtp_password, address: company.smtp_host }
+    mail(to: user.email, subject: "Please see the Terms and Conditions attached", delivery_method_options: delivery_options)
   end
 end
 </ruby>

guides/source/active_record_querying.textile

@@ -1183,7 +1183,7 @@ Client.unscoped.all
 
 This method removes all scoping and will do a normal query on the table.
 
-Note that chaining +unscoped+ with a +scope+ does not work. In this cases, it is
+Note that chaining +unscoped+ with a +scope+ does not work. In these cases, it is
 recommended that you use the block form of +unscoped+:
 
 <ruby>

guides/source/caching_with_rails.textile

@@ -455,7 +455,7 @@ class ProductsController < ApplicationController
 end
 </ruby>
 
-Instead of a options hash, you can also simply pass in a model, Rails will use the methods +updated_at+ and +cache_key+ for setting +last_modified+ and +etag+:
+Instead of a options hash, you can also simply pass in a model, Rails will use the +updated_at+ and +cache_key+ methods for setting +last_modified+ and +etag+:
 
 <ruby>
 class ProductsController < ApplicationController

guides/source/debugging_rails_applications.textile

@@ -189,24 +189,19 @@ Redirected to #<Post:0x20af760>
 Completed in 0.01224 (81 reqs/sec) | DB: 0.00044 (3%) | 302 Found [http://localhost/posts]
 </shell>
 
+Adding extra logging like this makes it easy to search for unexpected or unusual behavior in your logs. If you add extra logging, be sure to make sensible use of log levels, to avoid filling your production logs with useless trivia.
+
 h4. Tagged Logging
 
-When running a multi-user, multi-account application, it’s a great help to be able to filter the log by who did what. TaggedLogging in Active Support helps in doing exactly that by stamping log lines with subdomains, request ids, and anything else to aid debugging such applications.
+When running multi-user, multi-account applications, it’s often useful to be able to filter the logs using some custom rules. +TaggedLogging+ in Active Support helps in doing exactly that by stamping log lines with subdomains, request ids, and anything else to aid debugging such applications.
+
 <ruby>
-logger.tagged("custom_tag") { logger.info "Date is #{Time.now.to_date}" }
-logger.tagged("custom_tag", "gaurish") { logger.info "multiple tags are supported" }
+logger = ActiveSupport::TaggedLogging.new(Logger.new(STDOUT))
+logger.tagged("BCX") { logger.info "Stuff" }                            # Logs "[BCX] Stuff"
+logger.tagged("BCX", "Jason") { logger.info "Stuff" }                   # Logs "[BCX] [Jason] Stuff"
+logger.tagged("BCX") { logger.tagged("Jason") { logger.info "Stuff" } } # Logs "[BCX] [Jason] Stuff"
 </ruby>
 
-Now, you filter logs by searching for +custom_tag+ &  logs with tag +custom_tag+ would be returned. Here's an example using <tt>grep</tt> command
-<shell>
- $ grep custom_tag log/development.log 
-[custom_tag] Date is 2012-09-03
-[custom_tag] [gaurish] multiple tags are supported  
-</shell>
-Tagged Logging makes it easier to filter logs & exact selected lines only. For more details and examples, check the API documentation, see "<tt>TaggedLogging</tt>":http://api.rubyonrails.org/classes/ActiveSupport/TaggedLogging.html
-
-Adding extra logging like this makes it easy to search for unexpected or unusual behavior in your logs. If you add extra logging, be sure to make sensible use of log levels, to avoid filling your production logs with useless trivia.
-
 h3. Debugging with the +debugger+ gem
 
 When your code is behaving in unexpected ways, you can try printing to logs or the console to diagnose the problem. Unfortunately, there are times when this sort of error tracking is not effective in finding the root cause of a problem. When you actually need to journey into your running source code, the debugger is your best companion.

guides/source/form_helpers.textile

@@ -82,7 +82,7 @@ h4. Multiple Hashes in Form Helper Calls
 
 The +form_tag+ helper accepts 2 arguments: the path for the action and an options hash. This hash specifies the method of form submission and HTML options such as the form element's class.
 
-As with the +link_to+ helper, the path argument doesn't have to be given as a string; it can be a hash of URL parameters recognizable by Rails' routing mechanism, which will turn the hash into a valid URL. However, since both arguments to +form_tag+ are hashes, you can easily run into a problem if you would like to specify both. For instance, let's say you write this:
+As with the +link_to+ helper, the path argument doesn't have to be a string; it can be a hash of URL parameters recognizable by Rails' routing mechanism, which will turn the hash into a valid URL. However, since both arguments to +form_tag+ are hashes, you can easily run into a problem if you would like to specify both. For instance, let's say you write this:
 
 <ruby>
 form_tag(:controller => "people", :action => "search", :method => "get", :class => "nifty_form")