Fix typos, positive/negative statements, etc. (#51)

Author: keithrbennett

_src/3.2.md

@@ -550,7 +550,7 @@ Returns instances of `Refinement` used in the current context.
   p Module.used_refinements #=> []
   ```
 * **Notes:**
-  * Note that `used_refinements` is a _class_ method of a `Module`, and put there just for organizational purposes, while returning refinements list of the _current context_. There is no way to ask arbitrary module which refinements it uses (e.g., there is no `Calculator.used_refiments`).
+  * Note that `used_refinements` is a _class_ method of a `Module`, and put there just for organizational purposes, while returning refinements list of the _current context_. There is no way to ask arbitrary module which refinements it uses (e.g., there is no `Calculator.used_refinements`).
   * Just as a point of interest, the method with this name was proposed short after introducing of concept of refinements and was [discussed](https://bugs.ruby-lang.org/issues/7418) even before 2.0 release. It eventually became [Module.used_modules](https://docs.ruby-lang.org/en/3.2/Module.html#method-c-used_modules) introduced [in 2.4](2.4.html#moduleused_modules): that method just returned a list of modules with refinements, enabled in the current scope via `using`. The result of this method is not very fine-grained (as one refining method can refine _many_ objects at once, and it is impossible to inspect which exactly and what methods were added). After introduction of the `Refinement` class [in 3.1](3.1.html#refinement-class) it became reasonable to give easier access to particular refinements available in the current context.
 
 ### Integer#ceildiv
@@ -718,7 +718,7 @@ The method produces frozen and deduplicated string without changing the receiver
 
 The new protocol for `Time.new` is introduced, that parses Time from string.
 
-* **Reason:** Before Ruby 3.2, there core class `Time` provided no way to to get back a `Time` value from any serialization, including even simple `Time#inspect` or `#to_s`. The `Time.parse` provided by standard library `time` (not core functionality, doesn't work with explicit `require 'time'`), and tries to parse every imaginable format, while `Time.new` with string is stricter.
+* **Reason:** Before Ruby 3.2, there core class `Time` provided no way to to get back a `Time` value from any serialization, including even simple `Time#inspect` or `#to_s`. The `Time.parse` provided by standard library `time` (not core functionality, doesn't work without explicit `require 'time'`), and tries to parse every imaginable format, while `Time.new` with string is stricter.
 * **Discussion:** [Feature #18033](https://bugs.ruby-lang.org/issues/18033)
 * **Documentation:** [Time.new](https://docs.ruby-lang.org/en/3.2/Time.html#method-c-new)
 * **Code:**
@@ -1107,7 +1107,7 @@ Previously a part of standard library, Set (a collection of unique elements) was
   ```
 * **Notes:**
   * In general, inheriting from core classes is a questionable practice, and you probably should avoid it;
-  * Despite producing an instance of a subclass now, `#dup` doesn't call `#initialize_dup` constructor, so no custom data that you've associated with a subclass instance can't be preserved:
+  * Despite producing an instance of a subclass now, `#dup` doesn't call `#initialize_dup` constructor, so custom data that you've associated with a subclass instance can't be preserved:
     ```ruby
     class TaggedProc < Proc
       attr_reader :tag
@@ -1127,13 +1127,13 @@ Previously a part of standard library, Set (a collection of unique elements) was
     t.tag #=> 'test'
     t.dup.tag #=> nil
     ```
-  This is a [bug](https://bugs.ruby-lang.org/issues/19362) and will probably [change](https://github.com/ruby/ruby/pull/7178) in Ruby 3.2.1.
+  This is a [bug](https://bugs.ruby-lang.org/issues/19362) and will probably [change](https://github.com/ruby/ruby/pull/7178) in Ruby 3.2.2.
 
 #### `Proc#parameters`: new keyword argument `lambda: true/false`
 
 `parameters(lambda: true)` returns Proc parameters description _as if the proc was lambda_ (e.g. the parameters without defaults was mandatory), regardless of Proc's real "lambdiness."
 
-* **Reason:** The regular (non-lamba) proc always reports its positional arguments is optional. It corresponds to its behavior, but loses the information which of them have default values defined. It might be inconvenient when using procs in metaprogramming, like building wrapper objects, or defining methods based on procs.
+* **Reason:** The regular (non-lambda) proc always reports its positional arguments is optional. It corresponds to its behavior, but loses the information which of them have default values defined. It might be inconvenient when using procs in metaprogramming, like building wrapper objects, or defining methods based on procs.
 * **Discussion:** [Feature #15357](https://bugs.ruby-lang.org/issues/15357)
 * **Documentation:** [Proc#parameters](https://docs.ruby-lang.org/en/3.2/Proc.html#method-i-parameters)
 * **Code:**
@@ -1170,7 +1170,7 @@ Predicates to check method visibility added in Ruby 3.1 were reverted.
 
 #### `UnboundMethod`: more consistent reporting on what module it belongs to
 
-Since 3.2, `UnboundMethod`'s `#inspect` and comparison with other `UnboundMethod` only considers the module it defined in, not the actual module it was unbound from.
+Since 3.2, `UnboundMethod`'s `#inspect` and comparison with other `UnboundMethod` instances only considers the module it is defined in, not the actual module it was unbound from.
 
 * **Reason:** The change just aligns auxiliary methods with the main `UnboundMethod` implementation. No usage of unbound method is affected by what was the original class or object it was unbound from, only by the place of definition.
 * **Discussion:** [Feature #18798](https://bugs.ruby-lang.org/issues/18798)
@@ -1265,7 +1265,7 @@ The method can be redefined for providing custom "decoration" of exception messa
 
 * **Reason:** Standard libraries like `did_you_mean` (adds "did you mean _other name_" to `NoMethodError`) or `error_highlight` (printing of failed part of code and highlighting the problematic part) previously adjusted `Exception#message` method. It might not always be convenient: say, if an application wants to benefit from those gems, but also need to report "clear" error messages to a monitoring system, it required workaround. Starting from Ruby 3.2, there is a clear distinction:
   * `#message` is an original message with which the exception was raised;
-  * `#decorated_message` might be redefined by some libraries or user's code for convenience and better reporting (most probably);
+  * `#detailed_message` might be redefined by some libraries or user's code for convenience and better reporting (most probably);
   * `#full_message` ([introduced](2.5.html#exceptionfull_message) in 2.5) is what the interpreter prints: detailed message + error backtrace.
 * **Discussion:** [Feature #18564](https://bugs.ruby-lang.org/issues/18564)
 * **Documentation:** [Exception#detailed_message](https://docs.ruby-lang.org/en/3.2/Exception.html#method-i-detailed_message)
@@ -1352,7 +1352,7 @@ Returns the path of where the error have happened.
     puts e.path #=> test.rb
   end
   ```
-* **Note:** As of 3.2, there is no way to set `path` (unlike other additional exception data like `KeyError#key` that can be set in `#initialize`). As `SyntaxError` is mostly meant to be generate by Ruby parser and not by custom code, that might not be a big problem.
+* **Note:** As of 3.2, there is no way to set `path` (unlike other additional exception data like `KeyError#key` that can be set in `#initialize`). As `SyntaxError` is mostly meant to be generated by the Ruby parser and not by custom code, that might not be a big problem.
 
 ### Concurrency
 
@@ -1467,8 +1467,8 @@ A way for enumerating backtrace entries without instantiating them all.
   end
   ```
 * **Notes:**
-  * Note that while each item is printed as a regular string, they are actually instances of an utility class [Thread::Backtrace::Location](https://docs.ruby-lang.org/en/3.2/Thread/Backtrace/Location.html).
-  * The method _consciously_ doesn't have block-less version (which should've returned `Enumerator` as Enumerable's method like `#each` or `#map` do): this would defy the point of efficient backtrace analysis _at the current frame_, adding more frames of Enumerable/Enumerator implementations;
+  * Note that while each item is printed as a regular string, they are actually instances of a utility class [Thread::Backtrace::Location](https://docs.ruby-lang.org/en/3.2/Thread/Backtrace/Location.html).
+  * The method _intentionally_ doesn't have a block-less version (which should've returned `Enumerator` as Enumerable's method like `#each` or `#map` do): this would defy the point of efficient backtrace analysis _at the current frame_, adding more frames of Enumerable/Enumerator implementations;
   * For the reason of efficiency, `each_caller_location` returns nothing (again, to avoid materializing unnecessary objects), so if the goal is to find one location, as in example above, or select some part of the call stack, the only way to do it is non-idiomatic code:
     ```ruby
     lib = []
@@ -1496,7 +1496,7 @@ A way for enumerating backtrace entries without instantiating them all.
   # Or:
   GC.latest_gc_info(:need_major_by) #=> nil
   ```
-* **Notes:** The author of this changelog is not a GC expert, and the matter is not very well documented, so I only can say that the possible values (besides `nil`), according to feature's code, are `:nofree`, `:oldgen`, `:shady`, `:force`, and they are the same as `major_by:` possibe values. As far as I can guess, `major_by:` describes the latest major GC method, while `need_major_by:` describes the upcoming one; if it is `nil`, the major GC is not upcoming probably?..
+* **Notes:** The author of this changelog is not a GC expert, and the matter is not very well documented, so I only can say that the possible values (besides `nil`), according to feature's code, are `:nofree`, `:oldgen`, `:shady`, `:force`, and they are the same as `major_by:` possible values. As far as I can guess, `major_by:` describes the latest major GC method, while `need_major_by:` describes the upcoming one; if it is `nil`, the major GC is not upcoming probably?..
 
 #### `ObjectSpace`: dumping object shapes
 
@@ -1843,4 +1843,3 @@ A few changes to mention, though:
     25  end
   test.rb:3: syntax error, unexpected `end' (SyntaxError)
   ```
-