anchor.diff:  
   
   When using `breadth_first` mode the set of documents that fall into the uppermost buckets are
  -cached for subsequent replay so there is a memory overhead in doing this which is linear with the number of matching documents. 
  +cached for subsequent replay so there is a memory overhead in doing this which is linear with the number of matching documents.
   In most requests the volume of buckets generated is smaller than the number of documents that fall into them so the default `depth_first`
  -collection mode is normally the best bet but occasionally the `breadth_first` strategy can be significantly more efficient. Currently 
  +collection mode is normally the best bet but occasionally the `breadth_first` strategy can be significantly more efficient. Currently
   elasticsearch will always use the `depth_first` collect_mode unless explicitly instructed to use `breadth_first` as in the above example.
   Note that the `order` parameter can still be used to refer to data from a child aggregation when using the `breadth_first` setting - the parent
   aggregation understands that this child aggregation will need to be called first before any of the other child aggregations.
   
   WARNING: It is not possible to nest aggregations such as `top_hits` which require access to match score information under an aggregation that uses
   the `breadth_first` collection mode. This is because this would require a RAM buffer to hold the float score value for every document and
  -this would typically be too costly in terms of RAM. 
  -
  -
  +this would typically be too costly in terms of RAM.
  +
  +[[search-aggregations-bucket-terms-aggregation-execution-hint]]
   ==== Execution hint
   
   added[1.2.0] Added the `global_ordinals`, `global_ordinals_hash` and `global_ordinals_low_cardinality` execution modes
  
positive.code:          back by increasing `shard_size`.
           Setting `shard_min_doc_count` too high will cause terms to be filtered out on a shard level. This value should be set much lower than `min_doc_count/#shards`.
  
  ==== Script
  
  Generating the terms using a script:
  
negative.code: 
  ==== Calculating Document Count Error
  
  coming[1.4.0]
  
  There are two error values which can be shown on the terms aggregation.  The first gives a value for the aggregation as
  a whole which represents the maximum potential document count for a term which did not make it into the final list of
  terms. This is calculated as the sum of the document count from the last term returned from each shard .For the example
  given above the value would be 46 (2 + 15 + 29). This means that in the worst case scenario a term which was not returned
  could have the 4th highest document count.
  
  [source,js]
  