Fixed new typos, added a little info about ~sort versus "hint"s.

Objects/listsort.txt

@@ -431,7 +431,7 @@ at-a-time mode.
 
 A refinement:  The MergeState struct contains the value of min_gallop that
 controls when we enter galloping mode, initialized to MIN_GALLOP.
-merge_lo() and merge_hi() adjust this higher when gallooping isn't paying
+merge_lo() and merge_hi() adjust this higher when galloping isn't paying
 off, and lower when it is.
 
 
@@ -549,7 +549,7 @@ that merge_lo and merge_hi adjust:  the longer we stay in galloping mode,
 the smaller min_gallop gets, making it easier to transition back to
 galloping mode (if we ever leave it in the current merge, and at the
 start of the next merge).  But whenever the gallop loop doesn't pay,
-min_gallop is increased by one, making it harder to transition to back
+min_gallop is increased by one, making it harder to transition back
 to galloping mode (and again both within a merge and across merges).  For
 random data, this all but eliminates the gallop penalty:  min_gallop grows
 large enough that we almost never get into galloping mode.  And for cases
@@ -576,6 +576,12 @@ probably a better guess at the final result than either 0 or 9999.  But
 it's unclear how to generalize that intuition usefully, and merging of
 wildly unbalanced runs already enjoys excellent performance.
 
+~sort is a good example of when balanced runs could benefit from a better
+hint value:  to the extent possible, this would like to use a starting
+offset equal to the previous value of acount/bcount.  Doing so saves about
+10% of the compares in ~sort.  However, doing so is also a mixed bag,
+hurting other cases.
+
 
 Comparing Average # of Compares on Random Arrays
 ------------------------------------------------