honeymoose
/
OpenSearch
mirror of https://github.com/honeymoose/OpenSearch.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Fix formatting of the documentation. 

Remaining '@'s have been replaced with '`'s.
This commit is contained in:
Adrien Grand 2013-09-18 12:33:49 +02:00
parent db8f2be8bc
commit 90524d7ad2
6 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/reference/analysis/tokenfilters/stemmer-tokenfilter.asciidoc
View File

@ -2,7 +2,7 @@
=== Stemmer Token Filter
A filter that stems words (similar to `snowball`, but with more
options). The `language`/@name@ parameter controls the stemmer with the
options). The `language`/`name` parameter controls the stemmer with the
following available values:
http://lucene.apache.org/core/4_3_0/analyzers-common/index.html?org%2Fapache%2Flucene%2Fanalysis%2Far%2FArabicStemmer.html[arabic],

2
docs/reference/analysis/tokenizers/edgengram-tokenizer.asciidoc
View File

@ -64,7 +64,7 @@ of these classes. |`[]` (Keep all characters)
[float]
==== `side` deprecated
There used to be a @side@ parameter up to `0.90.1` but it is now deprecated. In
There used to be a `side` parameter up to `0.90.1` but it is now deprecated. In
order to emulate the behavior of `"side" : "BACK"` a
<<analysis-reverse-tokenfilter,`reverse` token filter>> should be used together
with the <<analysis-edgengram-tokenfilter,`edgeNGram` token filter>>. The

2
docs/reference/mapping/types/core-types.asciidoc
View File

@ -3,7 +3,7 @@
Each JSON field can be mapped to a specific core type. JSON itself
already provides us with some typing, with its support for `string`,
`integer`/@long@, `float`/@double@, `boolean`, and `null`.
`integer`/`long`, `float`/`double`, `boolean`, and `null`.
The following sample tweet JSON document will be used to explain the
core types:

2
docs/reference/mapping/types/geo-shape-type.asciidoc
View File

@ -38,7 +38,7 @@ specifies the desired precision and Elasticsearch will calculate the
best tree_levels value to honor this precision. The value should be a
number followed by an optional distance unit. Valid distance units
include: `in`, `inch`, `yd`, `yard`, `mi`, `miles`, `km`, `kilometers`,
`m`,@meters@ (default), `cm`,@centimeters@, `mm`, `millimeters`.
`m`,`meters` (default), `cm`,`centimeters`, `mm`, `millimeters`.
|`tree_levels` |Maximum number of layers to be used by the PrefixTree.
This can be used to control the precision of shape representations and

2
docs/reference/query-dsl/queries/custom-filters-score-query.asciidoc
View File

@ -39,7 +39,7 @@ performance, and boosting / script is considerably simpler.
A `score_mode` can be defined to control how multiple matching filters
control the score. By default, it is set to `first` which means the
first matching filter will control the score of the result. It can also
be set to `min`/@max@/@total@/@avg@/@multiply@ which will aggregate the
be set to `min`/`max`/`total`/`avg`/`multiply` which will aggregate the
result from all matching filters based on the aggregation type.
[float]

2
docs/reference/search/uri-request.asciidoc
View File

@ -68,7 +68,7 @@ not), comma delimited. Defaults to the internal `_source` field. Not
specifying any value will cause no fields to return.
|`sort` |Sorting to perform. Can either be in the form of `fieldName`, or
`fieldName:asc`/@fieldName:desc@. The fieldName can either be an actual
`fieldName:asc`/`fieldName:desc`. The fieldName can either be an actual
field within the document, or the special `_score` name to indicate
sorting based on scores. There can be several `sort` parameters (order
is important).