anchor.diff:  ----
   
   [[Suggester-MultipleDictionaries]]
  -==== Multiple Dictionaries
  +=== Multiple Dictionaries
   
   It is possible to include multiple `dictionaryImpl` definitions in a single SuggestComponent definition.
   
  
positive.code: ----
  
  [[Suggester-SuggesterSearchComponentParameters]]
  ==== Suggester Search Component Parameters
  
  The Suggester search component takes several configuration parameters. The choice of the lookup implementation (`lookupImpl`, how terms are found in the suggestion dictionary) and the dictionary implementation (`dictionaryImpl`, how terms are stored in the suggestion dictionary) will dictate some of the parameters required. Below are the main parameters that can be used no matter what lookup or dictionary implementation is used. In the following sections additional parameters are provided for each implementation.
  
  // TODO: Change column width to %autowidth.spread when https://github.com/asciidoctor/asciidoctor-pdf/issues/599 is fixed
  
  [cols="30,70",options="header"]
  |===
  |Parameter |Description
  |searchComponent name |Arbitrary name for the search component.
  |name |A symbolic name for this suggester. You can refer to this name in the URL parameters and in the SearchHandler configuration. It is possible to have mutiples of these
  |lookupImpl |Lookup implementation. There are several possible implementations, described below in the section <<Suggester-LookupImplementations,Lookup Implementations>>. If not set, the default lookup is JaspellLookupFactory.
  |dictionaryImpl |The dictionary implementation to use. There are several possible implementations, described below in the section <<Suggester-DictionaryImplementations,Dictionary Implementations>> . If not set, the default dictionary implementation is HighFrequencyDictionaryFactory unless a `sourceLocation` is used, in which case, the dictionary implementation will be FileDictionaryFactory
  |field a|
  A field from the index to use as the basis of suggestion terms. If `sourceLocation` is empty (meaning any dictionary implementation other than FileDictionaryFactory) then terms from this field in the index will be used.
  
  To be used as the basis for a suggestion, the field must be stored. You may want to <<copying-fields.adoc#copying-fields,use copyField rules>> to create a special 'suggest' field comprised of terms from other fields in documents. In any event, you likely want a minimal amount of analysis on the field, so an additional option is to create a field type in your schema that only uses basic tokenizers or filters. One option for such a field type is shown here:
  
  [source,xml]
  ----
  <fieldType class="solr.TextField" name="textSuggest" positionIncrementGap="100">
  
negative.code: [[Suggester-ContextFiltering]]
  === Context Filtering
  
  Context filtering lets you filter suggestions by a separate context field, such as category, department or any other token. The `AnalyzingInfixLookupFactory` and `BlendedInfixLookupFactory` currently support this feature, when backed by `DocumentDictionaryFactory`.
  
  Add `contextField` to your suggester configuration. This example will suggest names and allow to filter by category:
  
  