anchor.diff:  // CONSOLE
   // TEST[setup:twitter]
   
  -[[boundary-scanners]]
  -==== Boundary Scanners
  -
  -When highlighting a field using the unified highlighter or the fast vector highlighter,
  -you can specify how to break the highlighted fragments using `boundary_scanner`, which accepts
  -the following values:
  -
  -* `chars` (default mode for the FVH): allows to configure which characters (`boundary_chars`)
  -constitute a boundary for highlighting. It's a single string with each boundary
  -character defined in it (defaults to `.,!? \t\n`). It also allows configuring
  -the `boundary_max_scan` to control how far to look for boundary characters
  -(defaults to `20`). Works only with the Fast Vector Highlighter.
  -
  -* `sentence` and `word`: use Java's https://docs.oracle.com/javase/8/docs/api/java/text/BreakIterator.html[BreakIterator]
  -to break the highlighted fragments at the next  _sentence_ or _word_ boundary.
  -You can further specify `boundary_scanner_locale` to control which Locale is used
  -to search the text for these boundaries.
  -
  -[NOTE]
  -When used with the `unified` highlighter, the `sentence` scanner splits sentence
  -bigger than `fragment_size` at the first word boundary next to `fragment_size`.
  -You can set `fragment_size` to 0 to never split any sentence.
  -
   [[matched-fields]]
  -==== Matched Fields
  +===== Combining matches on multiple fields
   
   WARNING: This is only supported by the `fvh` highlighter
   
   The Fast Vector Highlighter can combine matches on multiple fields to
  -highlight a single field using `matched_fields`.  This is most
  -intuitive for multifields that analyze the same string in different
  -ways.  All `matched_fields` must have `term_vector` set to
  -`with_positions_offsets` but only the field to which the matches are
  -combined is loaded so only that field would benefit from having
  +highlight a single field.  This is most intuitive for multifields that
  +analyze the same string in different ways.  All `matched_fields` must have
  +`term_vector` set to `with_positions_offsets` but only the field to which
  +the matches are combined is loaded so only that field would benefit from having
   `store` set to `yes`.
   
  -In the following examples `comment` is analyzed by the `english`
  +In the following examples, `comment` is analyzed by the `english`
   analyzer and `comment.plain` is analyzed by the `standard` analyzer.
   
   [source,js]
  
positive.code: --------------------------------------------------
  // CONSOLE
  
  ====== Term Vectors
  
  If `term_vector` information is provided by setting `term_vector` to
  `with_positions_offsets` in the mapping then the `unified` highlighter
  will automatically use the `term_vector` to highlight the field.
  The `term_vector` highlighting is faster to highlight multi-term queries like
  `prefix` or `wildcard` because it can access the dictionary of term for each document
  but it is also usually more costly than using the `postings` directly.
  
  Here is an example of setting the `comment` field to allow for
  highlighting using the `term_vectors` (this will cause the index to be bigger):
  
  
negative.code: // TEST[setup:twitter]
  
  None of the highlighters built into Elasticsearch care about the order that the
  fields are highlighted but a plugin might.
  