Fix typos and markdowns

Found via these commands:

    codespell -L crate,ser,panting,beauti,hart,ue,atleast,childs,ond,pris,hel,mot
    markdownlint *.md doc/src/*.md --disable MD013 MD025 MD033 MD001 MD024 MD036 MD041 MD003

ARCHITECTURE.md

@@ -10,6 +10,7 @@ Tantivy's bread and butter is to address the problem of full-text search :
 Given a large set of textual documents, and a text query, return the K-most relevant documents in a very efficient way. To execute these queries rapidly, the tantivy needs to build an index beforehand. The relevance score implemented in the tantivy is not configurable. Tantivy uses the same score as the default similarity used in Lucene / Elasticsearch, called [BM25](https://en.wikipedia.org/wiki/Okapi_BM25).
 
 But tantivy's scope does not stop there. Numerous features are required to power rich-search applications. For instance, one may want to:
+
 - compute the count of documents matching a query in the different section of an e-commerce website,
 - display an average price per meter square for a real estate search engine,
 - take into account historical user data to rank documents in a specific way,
@@ -22,27 +23,28 @@ rapidly select all documents matching a given predicate (also known as a query)
 collect some information about them ([See collector](#collector-define-what-to-do-with-matched-documents)).
 
 Roughly speaking the design is following these guiding principles:
+
 - Search should be O(1) in memory.
 - Indexing should be O(1) in memory. (In practice it is just sublinear)
 - Search should be as fast as possible
 
 This comes at the cost of the dynamicity of the index: while it is possible to add, and delete documents from our corpus, the tantivy is designed to handle these updates in large batches.
 
-## [core/](src/core): Index, segments, searchers.
+## [core/](src/core): Index, segments, searchers
 
 Core contains all of the high-level code to make it possible to create an index, add documents, delete documents and commit.
 
 This is both the most high-level part of tantivy, the least performance-sensitive one, the seemingly most mundane code... And paradoxically the most complicated part.
 
-### Index and Segments...
+### Index and Segments
 
-A tantivy index is a collection of smaller independent immutable segments. 
+A tantivy index is a collection of smaller independent immutable segments.
 Each segment contains its own independent set of data structures.
 
 A segment is identified by a segment id that is in fact a UUID.
 The file of a segment has the format
 
- ```segment-id . ext ```
+ ```segment-id . ext```
 
 The extension signals which data structure (or [`SegmentComponent`](src/core/segment_component.rs)) is stored in the file.
 
@@ -52,17 +54,15 @@ On commit, one segment per indexing thread is written to disk, and the `meta.jso
 
 For a better idea of how indexing works, you may read the [following blog post](https://fulmicoton.com/posts/behold-tantivy-part2/).
 
-
 ### Deletes
 
 Deletes happen by deleting a "term". Tantivy does not offer any notion of primary id, so it is up to the user to use a field in their schema as if it was a primary id, and delete the associated term if they want to delete only one specific document.
 
 On commit, tantivy will find all of the segments with documents matching this existing term and remove from [alive bitset file](src/fastfield/alive_bitset.rs) that represents the bitset of the alive document ids.
-Like all segment files, this file is immutable. Because it is possible to have more than one alive bitset file at a given instant, the alive bitset filename has the format ``` segment_id . commit_opstamp . del```.
+Like all segment files, this file is immutable. Because it is possible to have more than one alive bitset file at a given instant, the alive bitset filename has the format ```segment_id . commit_opstamp . del```.
 
 An opstamp is simply an incremental id that identifies any operation applied to the index. For instance, performing a commit or adding a document.
 
-
 ### DocId
 
 Within a segment, all documents are identified by a DocId that ranges within `[0, max_doc)`.
@@ -74,6 +74,7 @@ The DocIds are simply allocated in the order documents are added to the index.
 
 In separate threads, tantivy's index writer search for opportunities to merge segments.
 The point of segment merge is to:
+
 - eventually get rid of tombstoned documents
 - reduce the otherwise ever-growing number of segments.
 
@@ -104,6 +105,7 @@ Tantivy's document follows a very strict schema, decided before building any ind
 The schema defines all of the fields that the indexes [`Document`](src/schema/document.rs) may and should contain, their types (`text`, `i64`, `u64`, `Date`, ...) as well as how it should be indexed / represented in tantivy.
 
 Depending on the type of the field, you can decide to
+
 - put it in the docstore
 - store it as a fast field
 - index it
@@ -117,9 +119,10 @@ As of today, tantivy's schema imposes a 1:1 relationship between a field that is
 
 This is not something tantivy supports, and it is up to the user to duplicate field / concatenate fields before feeding them to tantivy.
 
-## General information about these data structures.
+## General information about these data structures
 
 All data structures in tantivy, have:
+
 - a writer
 - a serializer
 - a reader
@@ -132,7 +135,7 @@ This conversion is done by the serializer.
 Finally, the reader is in charge of offering an API to read on this on-disk read-only representation.
 In tantivy, readers are designed to require very little anonymous memory. The data is read straight from an mmapped file, and loading an index is as fast as mmapping its files.
 
-## [store/](src/store): Here is my DocId, Gimme my document!
+## [store/](src/store): Here is my DocId, Gimme my document
 
 The docstore is a row-oriented storage that, for each document, stores a subset of the fields
 that are marked as stored in the schema. The docstore is compressed using a general-purpose algorithm
@@ -146,6 +149,7 @@ Once the top 10 documents have been identified, we fetch them from the store, an
 **Not useful for**
 
 Fetching a document from the store is typically a "slow" operation. It usually consists in
+
 - searching into a compact tree-like data structure to find the position of the right block.
 - decompressing a small block
 - returning the document from this block.
@@ -154,8 +158,7 @@ It is NOT meant to be called for every document matching a query.
 
 As a rule of thumb, if you hit the docstore more than 100 times per search query, you are probably misusing tantivy.
 
-
-## [fastfield/](src/fastfield): Here is my DocId, Gimme my value!
+## [fastfield/](src/fastfield): Here is my DocId, Gimme my value
 
 Fast fields are stored in a column-oriented storage that allows for random access.
 The only compression applied is bitpacking. The column comes with two meta data.
@@ -163,7 +166,7 @@ The minimum value in the column and the number of bits per doc.
 
 Fetching a value for a `DocId` is then as simple as computing
 
-```
+```rust
 min_value + fetch_bits(num_bits * doc_id..num_bits * (doc_id+1))
 ```
 
@@ -190,7 +193,7 @@ For advanced search engine, it is possible to store all of the features required
 
 Finally facets are a specific kind of fast field, and the associated source code is in [`fastfield/facet_reader.rs`](src/fastfield/facet_reader.rs).
 
-# The inverted search index.
+# The inverted search index
 
 The inverted index is the core part of full-text search.
 When presented a new document with the text field "Hello, happy tax payer!", tantivy breaks it into a list of so-called tokens. In addition to just splitting these strings into tokens, it might also do different kinds of operations like dropping the punctuation, converting the character to lowercase, apply stemming, etc. Tantivy makes it possible to configure the operations to be applied in the schema (tokenizer/ is the place where these operations are implemented).
@@ -215,19 +218,18 @@ The inverted index actually consists of two data structures chained together.
 
 Where [TermInfo](src/postings/term_info.rs) is an object containing some meta data about a term.
 
-
-## [termdict/](src/termdict): Here is a term, give me the [TermInfo](src/postings/term_info.rs)!
+## [termdict/](src/termdict): Here is a term, give me the [TermInfo](src/postings/term_info.rs)
 
 Tantivy's term dictionary is mainly in charge of supplying the function
 
 [Term](src/schema/term.rs) ⟶ [TermInfo](src/postings/term_info.rs)
 
 It is itself broken into two parts.
+
 - [Term](src/schema/term.rs) ⟶ [TermOrdinal](src/termdict/mod.rs) is addressed by a finite state transducer, implemented by the fst crate.
 - [TermOrdinal](src/termdict/mod.rs) ⟶ [TermInfo](src/postings/term_info.rs) is addressed by the term info store.
 
-
-## [postings/](src/postings): Iterate over documents... very fast!
+## [postings/](src/postings): Iterate over documents... very fast
 
 A posting list makes it possible to store a sorted list of doc ids and for each doc store
 a term frequency as well.
@@ -257,7 +259,6 @@ we advance the position reader by the number of term frequencies of the current
 The [BM25](https://en.wikipedia.org/wiki/Okapi_BM25) formula also requires to know the number of tokens stored in a specific field for a given document. We store this information on one byte per document in the fieldnorm.
 The fieldnorm is therefore compressed. Values up to 40 are encoded unchanged.
 
-
 ## [tokenizer/](src/tokenizer): How should we process text?
 
 Text processing is key to a good search experience.
@@ -268,7 +269,6 @@ Text processing can be configured by selecting an off-the-shelf [`Tokenizer`](./
 
 Tantivy's comes with few tokenizers, but external crates are offering advanced tokenizers, such as [Lindera](https://crates.io/crates/lindera) for Japanese.
 
-
 ## [query/](src/query): Define and compose queries
 
 The [Query](src/query/query.rs) trait defines what a query is.

CHANGELOG.md

@@ -1,5 +1,6 @@
 Tantivy 0.19
 ================================
+
 - Updated [Date Field Type](https://github.com/quickwit-oss/tantivy/pull/1396)
   The `DateTime` type has been updated to hold timestamps with microseconds precision.
   `DateOptions` and `DatePrecision` have been added to configure Date fields. The precision is used to hint on fast values compression. Otherwise, seconds precision is used everywhere else (i.e terms, indexing).
@@ -7,6 +8,7 @@ Tantivy 0.19
 
 Tantivy 0.18
 ================================
+
 - For date values `chrono` has been replaced with `time` (@uklotzde) #1304 :
   - The `time` crate is re-exported as `tantivy::time` instead of `tantivy::chrono`.
   - The type alias `tantivy::DateTime` has been removed.
@@ -22,6 +24,7 @@ Tantivy 0.18
 
 Tantivy 0.17
 ================================
+
 - LogMergePolicy now triggers merges if the ratio of deleted documents reaches a threshold (@shikhar @fulmicoton) [#115](https://github.com/quickwit-oss/tantivy/issues/115)
 - Adds a searcher Warmer API (@shikhar @fulmicoton)
 - Change to non-strict schema. Ignore fields in data which are not defined in schema. Previously this returned an error. #1211
@@ -36,33 +39,39 @@ Tantivy 0.17
 
 Tantivy 0.16.2
 ================================
+
 - Bugfix in FuzzyTermQuery. (transposition_cost_one was not doing anything)
 
 Tantivy 0.16.1
 ========================
+
 - Major Bugfix on multivalued fastfield.  #1151
 - Demux operation (@PSeitz)
 
 Tantivy 0.16.0
 =========================
+
 - Bugfix in the filesum check. (@evanxg852000) #1127
 - Bugfix in positions when the index is sorted by a field. (@appaquet) #1125
 
 Tantivy 0.15.3
 =========================
-- Major bugfix. Deleting documents was broken when the index was sorted by a field. (@appaquet, @fulmicoton) #1101
 
+- Major bugfix. Deleting documents was broken when the index was sorted by a field. (@appaquet, @fulmicoton) #1101
 
 Tantivy 0.15.2
 ========================
+
 - Major bugfix. DocStore still panics when a deleted doc is at the beginning of a block. (@appaquet) #1088
 
 Tantivy 0.15.1
 =========================
+
 - Major bugfix. DocStore panics when first block is deleted. (@appaquet) #1077
 
 Tantivy 0.15.0
 =========================
+
 - API Changes. Using Range instead of (start, end) in the API and internals (`FileSlice`, `OwnedBytes`, `Snippets`, ...)
   This change is breaking but migration is trivial.
 - Added an Histogram collector. (@fulmicoton) #994
@@ -84,9 +93,9 @@ Tantivy 0.15.0
 - Updated TermMerger implementation to rely on the union feature of the FST (@scampi) #469
 - Add boolean marking whether position is required in the query_terms API call (@fulmicoton). #1070
 
-
 Tantivy 0.14.0
 =========================
+
 - Remove dependency to atomicwrites #833 .Implemented by @fulmicoton upon suggestion and research from @asafigan).
 - Migrated tantivy error from the now deprecated `failure` crate to `thiserror` #760. (@hirevo)
 - API Change. Accessing the typed value off a `Schema::Value` now returns an Option instead of panicking if the type does not match.
@@ -105,16 +114,19 @@ This version breaks compatibility and requires users to reindex everything.
 
 Tantivy 0.13.2
 ===================
+
 Bugfix. Acquiring a facet reader on a segment that does not contain any
 doc with this facet returns `None`. (#896)
 
 Tantivy 0.13.1
 ===================
+
 Made `Query` and `Collector` `Send + Sync`.
 Updated misc dependency versions.
 
 Tantivy 0.13.0
 ======================
+
 Tantivy 0.13 introduce a change in the index format that will require
 you to reindex your index (BlockWAND information are added in the skiplist).
 The index size increase is minor as this information is only added for
@@ -129,6 +141,7 @@ so that we can discuss possible solutions.
 A freshly created DocSet point directly to their first doc. A sentinel value called TERMINATED marks the end of a DocSet.
 `.advance()` returns the new DocId. `Scorer::skip(target)` has been replaced by `Scorer::seek(target)` and returns the resulting DocId.
 As a result, iterating through DocSet now looks as follows
+
 ```rust
 let mut doc = docset.doc();
 while doc != TERMINATED {
@@ -136,7 +149,9 @@ while doc != TERMINATED {
    doc = docset.advance();
 }
 ```
+
 The change made it possible to greatly simplify a lot of the docset's code.
+
 - Misc internal optimization and introduction of the `Scorer::for_each_pruning` function. (@fulmicoton)
 - Added an offset option to the Top(.*)Collectors. (@robyoung)
 - Added Block WAND. Performance on TOP-K on term-unions should be greatly increased. (@fulmicoton, and special thanks
@@ -144,6 +159,7 @@ to the PISA team for answering all my questions!)
 
 Tantivy 0.12.0
 ======================
+
 - Removing static dispatch in tokenizers for simplicity. (#762)
 - Added backward iteration for `TermDictionary` stream. (@halvorboe)
 - Fixed a performance issue when searching for the posting lists of a missing term (@audunhalland)
@@ -154,30 +170,32 @@ Tantivy 0.12.0
 ## How to update?
 
 Crates relying on custom tokenizer, or registering tokenizer in the manager will require some
-minor changes. Check https://github.com/quickwit-oss/tantivy/blob/main/examples/custom_tokenizer.rs
+minor changes. Check <https://github.com/quickwit-oss/tantivy/blob/main/examples/custom_tokenizer.rs>
 to check for some code sample.
 
 Tantivy 0.11.3
 =======================
+
 - Fixed DateTime as a fast field (#735)
 
 Tantivy 0.11.2
 =======================
+
 - The future returned by `IndexWriter::merge` does not borrow `self` mutably anymore (#732)
 - Exposing a constructor for `WatchHandle` (#731)
 
 Tantivy 0.11.1
 =====================
-- Bug fix #729
 
+- Bug fix #729
 
 Tantivy 0.11.0
 =====================
 
 - Added f64 field. Internally reuse u64 code the same way i64 does (@fdb-hiroshima)
 - Various bugfixes in the query parser.
-    - Better handling of hyphens in query parser. (#609)
-    - Better handling of whitespaces.
+  - Better handling of hyphens in query parser. (#609)
+  - Better handling of whitespaces.
 - Closes #498 - add support for Elastic-style unbounded range queries for alphanumeric types eg. "title:>hello", "weight:>=70.5", "height:<200" (@petr-tik)
 - API change around `Box<BoxableTokenizer>`. See detail in #629
 - Avoid rebuilding Regex automaton whenever a regex query is reused. #639 (@brainlock)
@@ -208,7 +226,6 @@ Tantivy 0.10.1
 Avoid watching the mmap directory until someone effectively creates a reader that uses
 this functionality.
 
-
 Tantivy 0.10.0
 =====================
 
@@ -224,6 +241,7 @@ Tantivy 0.10.0
 
 Minor
 ---------
+
 - Switched to Rust 2018 (@uvd)
 - Small simplification of the code.
 Calling .freq() or .doc() when .advance() has never been called
@@ -231,8 +249,7 @@ on segment postings should panic from now on.
 - Tokens exceeding `u16::max_value() - 4` chars are discarded silently instead of panicking.
 - Fast fields are now preloaded when the `SegmentReader` is created.
 - `IndexMeta` is now public.  (@hntd187)
-- `IndexWriter` `add_document`, `delete_term`. `IndexWriter` is `Sync`, making it possible to use it with a `
-Arc<RwLock<IndexWriter>>`. `add_document` and `delete_term` can
+- `IndexWriter` `add_document`, `delete_term`. `IndexWriter` is `Sync`, making it possible to use it with a `Arc<RwLock<IndexWriter>>`. `add_document` and `delete_term` can
 only require a read lock. (@fulmicoton)
 - Introducing `Opstamp` as an expressive type alias for `u64`. (@petr-tik)
 - Stamper now relies on `AtomicU64` on all platforms (@petr-tik)
@@ -248,16 +265,17 @@ Your program should be usable as is.
 Fast fields used to be accessed directly from the `SegmentReader`.
 The API changed, you are now required to acquire your fast field reader via the
 `segment_reader.fast_fields()`, and use one of the typed method:
+
 - `.u64()`, `.i64()` if your field is single-valued ;
 - `.u64s()`, `.i64s()` if your field is multi-valued ;
 - `.bytes()` if your field is bytes fast field.
 
-
-
 Tantivy 0.9.0
 =====================
+
 *0.9.0 index format is not compatible with the
 previous index format.*
+
 - MAJOR BUGFIX :
   Some `Mmap` objects were being leaked, and would never get released. (@fulmicoton)
 - Removed most unsafe (@fulmicoton)
@@ -301,37 +319,40 @@ To update from tantivy 0.8, you will need to go through the following steps.
 
     ```
 
-
 Tantivy 0.8.2
 =====================
+
 Fixing build for x86_64 platforms. (#496)
 No need to update from 0.8.1 if tantivy
 is building on your platform.
 
-
 Tantivy 0.8.1
 =====================
+
 Hotfix of #476.
 
 Merge was reflecting deletes before commit was passed.
 Thanks @barrotsteindev  for reporting the bug.
 
-
 Tantivy 0.8.0
 =====================
+
 *No change in the index format*
+
 - API Breaking change in the collector API. (@jwolfe, @fulmicoton)
 - Multithreaded search (@jwolfe, @fulmicoton)
 
-
 Tantivy 0.7.1
 =====================
+
 *No change in the index format*
+
 - Bugfix: NGramTokenizer panics on non ascii chars
 - Added a space usage API
 
 Tantivy 0.7
 =====================
+
 - Skip data for doc ids and positions (@fulmicoton),
   greatly improving performance
 - Tantivy error now rely on the failure crate (@drusellers)
@@ -341,15 +362,15 @@ Tantivy 0.7
 
 Tantivy 0.6.1
 =========================
+
 - Bugfix #324. GC removing was removing file that were still in useful
 - Added support for parsing AllQuery and RangeQuery via QueryParser
-    - AllQuery: `*`
-    - RangeQuery:
-        - Inclusive `field:[startIncl to endIncl]`
-        - Exclusive `field:{startExcl to endExcl}`
-        - Mixed `field:[startIncl to endExcl}` and vice versa
-        - Unbounded `field:[start to *]`, `field:[* to end]`
-
+  - AllQuery: `*`
+  - RangeQuery:
+    - Inclusive `field:[startIncl to endIncl]`
+    - Exclusive `field:{startExcl to endExcl}`
+    - Mixed `field:[startIncl to endExcl}` and vice versa
+    - Unbounded `field:[start to *]`, `field:[* to end]`
 
 Tantivy 0.6
 ==========================
@@ -362,58 +383,53 @@ to this release!
 - Approximate field norms encoded over 1 byte. (@fulmicoton)
 - Compiles on stable rust (@fulmicoton)
 - Add &[u8] fastfield for associating arbitrary bytes to each document (@jason-wolfe) (#270)
-    - Completely uncompressed
-    - Internally: One u64 fast field for indexes, one fast field for the bytes themselves.
+  - Completely uncompressed
+  - Internally: One u64 fast field for indexes, one fast field for the bytes themselves.
 - Add NGram token support (@drusellers)
 - Add Stopword Filter support (@drusellers)
 - Add a FuzzyTermQuery (@drusellers)
 - Add a RegexQuery (@drusellers)
 - Various performance improvements (@fulmicoton)_
 
-
 Tantivy 0.5.2
 ===========================
+
 - bugfix #274
 - bugfix #280
 - bugfix #289
 
-
 Tantivy 0.5.1
 ==========================
-- bugfix #254 : tantivy failed if no documents in a segment contained a specific field.
 
+- bugfix #254 : tantivy failed if no documents in a segment contained a specific field.
 
 Tantivy 0.5
 ==========================
+
 - Faceting
 - RangeQuery
 - Configurable tokenization pipeline
 - Bugfix in PhraseQuery
 - Various query optimisation
 - Allowing very large indexes
-    - 64 bits file address
-    - Smarter encoding of the `TermInfo` objects
-
-
+  - 64 bits file address
+  - Smarter encoding of the `TermInfo` objects
 
 Tantivy 0.4.3
 ==========================
 
 - Bugfix race condition when deleting files. (#198)
 
-
 Tantivy 0.4.2
 ==========================
 
 - Prevent usage of AVX2 instructions (#201)
 
-
 Tantivy 0.4.1
 ==========================
 
 - Bugfix for non-indexed fields. (#199)
 
-
 Tantivy 0.4.0
 ==========================
 
@@ -428,37 +444,31 @@ Tantivy 0.4.0
   - Searching for a non-indexed field returns an explicit Error
   - Phrase query for non-tokenized field are not tokenized by the query parser.
 - Faster/Better indexing (@fulmicoton)
-    - using murmurhash2
-    - faster merging
-    - more memory efficient fast field writer (@lnicola )
-    - better handling of collisions
-    - lesser memory usage
+  - using murmurhash2
+  - faster merging
+  - more memory efficient fast field writer (@lnicola )
+  - better handling of collisions
+  - lesser memory usage
 - Added API, most notably to iterate over ranges of terms (@fulmicoton)
 - Bugfix that was preventing to unmap segment files, on index drop (@fulmicoton)
 - Made the doc! macro public (@fulmicoton)
 - Added an alternative implementation of the streaming dictionary (@fulmicoton)
 
-
-
 Tantivy 0.3.1
 ==========================
 
 - Expose a method to trigger files garbage collection
 
-
-
 Tantivy 0.3
 ==========================
 
-
 Special thanks to @Kodraus @lnicola @Ameobea @manuel-woelker @celaus
 for their contribution to this release.
 
 Thanks also to everyone in tantivy gitter chat
 for their advise and company :)
 
-https://gitter.im/tantivy-search/tantivy
-
+<https://gitter.im/tantivy-search/tantivy>
 
 Warning:
 
@@ -467,19 +477,16 @@ code and index format.
 You should not expect backward compatibility before
 tantivy 1.0.
 
-
-
 New Features
 ------------
 
 - Delete. You can now delete documents from an index.
 - Support for windows (Thanks to @lnicola)
 
-
 Various Bugfixes & small improvements
 ----------------------------------------
 
-- Added CI for Windows (https://ci.appveyor.com/project/fulmicoton/tantivy)
+- Added CI for Windows (<https://ci.appveyor.com/project/fulmicoton/tantivy>)
 Thanks to @KodrAus ! (#108)
 - Various dependy version update (Thanks to @Ameobea) #76
 - Fixed several race conditions in `Index.wait_merge_threads`
@@ -491,7 +498,3 @@ Thanks to @KodrAus ! (#108)
 - Building binary targets for tantivy-cli (Thanks to @KodrAus)
 - Misc invisible bug fixes, and code cleanup.
 - Use
-
-
-
-

README.md

@@ -5,7 +5,6 @@
 [![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT)
 [![Crates.io](https://img.shields.io/crates/v/tantivy.svg)](https://crates.io/crates/tantivy)
 
-
 ![Tantivy](https://tantivy-search.github.io/logo/tantivy-logo.png)
 
 **Tantivy** is a **full-text search engine library** written in Rust.
@@ -16,7 +15,7 @@ to build such a search engine.
 
 Tantivy is, in fact, strongly inspired by Lucene's design.
 
-If you are looking for an alternative to Elasticsearch or Apache Solr, check out [Quickwit](https://github.com/quickwit-oss/quickwit), our search engine built on top of Tantivy. 
+If you are looking for an alternative to Elasticsearch or Apache Solr, check out [Quickwit](https://github.com/quickwit-oss/quickwit), our search engine built on top of Tantivy.
 
 # Benchmark
 
@@ -57,7 +56,6 @@ Your mileage WILL vary depending on the nature of queries and their load.
 
 Distributed search is out of the scope of Tantivy, but if you are looking for this feature, check out [Quickwit](https://github.com/quickwit-oss/quickwit/).
 
-
 # Getting started
 
 Tantivy works on stable Rust (>= 1.27) and supports Linux, macOS, and Windows.
@@ -125,7 +123,8 @@ By default, `rustc` compiles everything in the `examples/` directory in debug mo
 rust-gdb target/debug/examples/$EXAMPLE_NAME
 $ gdb run
 ```
-# Companies Using Tantivy 
+
+# Companies Using Tantivy
 
 <p align="left">
 <img align="center" src="doc/assets/images/Nuclia.png#gh-light-mode-only" alt="Nuclia" height="25" width="auto" /> &nbsp;
@@ -134,11 +133,12 @@ $ gdb run
 <img align="center" src="doc/assets/images/nuclia-dark-theme.png#gh-dark-mode-only" alt="Nuclia" height="35" width="auto" /> &nbsp;
 <img align="center" src="doc/assets/images/humanfirst.ai-dark-theme.png#gh-dark-mode-only" alt="Humanfirst.ai" height="25" width="auto" />&nbsp; &nbsp;
 <img align="center" src="doc/assets/images/element-dark-theme.png#gh-dark-mode-only" alt="Element.io" height="25" width="auto" />
-</p> 
-
+</p>
 
 # FAQ
+
 ### Can I use Tantivy in other languages?
+
 - Python → [tantivy-py](https://github.com/quickwit-oss/tantivy-py)
 - Ruby → [tantiny](https://github.com/baygeldin/tantiny)
 
@@ -152,13 +152,17 @@ You can also find other bindings on [GitHub](https://github.com/search?q=tantivy
 - and [more](https://github.com/search?q=tantivy)!
 
 ### On average, how much faster is Tantivy compared to Lucene?
+
 - According to our [search latency benchmark](https://tantivy-search.github.io/bench/), Tantivy is approximately 2x faster than Lucene.
 
 ### Does tantivy support incremental indexing?
+
 - Yes.
 
 ### How can I edit documents?
+
 - Data in tantivy is immutable. To edit a document, the document needs to be deleted and reindexed.
 
 ### When will my documents be searchable during indexing?
+
 - Documents will be searchable after a `commit` is called on an `IndexWriter`. Existing `IndexReader`s will also need to be reloaded in order to reflect the changes. Finally, changes are only visible to newly acquired `Searcher`.

common/src/serialize.rs

@@ -19,7 +19,7 @@ pub trait DeserializeFrom<T: BinarySerializable> {
 
 /// Implement deserialize from &[u8] for all types which implement BinarySerializable.
 ///
-/// TryFrom would actually be preferrable, but not possible because of the orphan
+/// TryFrom would actually be preferable, but not possible because of the orphan
 /// rules (not completely sure if this could be resolved)
 impl<T: BinarySerializable> DeserializeFrom<T> for &[u8] {
     fn deserialize(&mut self) -> io::Result<T> {

doc/src/SUMMARY.md

@@ -1,7 +1,5 @@
 # Summary
 
-
-
 [Avant Propos](./avant-propos.md)
 
 - [Segments](./basis.md)

doc/src/avant-propos.md

@@ -3,7 +3,7 @@
 > Tantivy is a **search** engine **library** for Rust.
 
 If you are familiar with Lucene, it's an excellent approximation to consider tantivy as Lucene for rust. tantivy is heavily inspired by Lucene's design and
-they both have the same scope and targetted use cases.
+they both have the same scope and targeted use cases.
 
 If you are not familiar with Lucene, let's break down our little tagline.
 
@@ -31,4 +31,4 @@ relevancy, collapsing, highlighting, spatial search.
   index from a different format.
 
   Tantivy exposes a lot of low level API to do all of these things.
-  
+  

doc/src/basis.md

@@ -11,7 +11,7 @@ directory shipped with tantivy is the `MmapDirectory`.
 While this design has some downsides, this greatly simplifies the source code of
 tantivy. Caching is also entirely delegated to the OS.
 
-`tantivy` works entirely (or almost) by directly reading the datastructures as they are layed on disk. As a result, the act of opening an indexing does not involve loading different datastructures from the disk into random access memory : starting a process, opening an index, and performing your first query can typically be done in a matter of milliseconds.
+`tantivy` works entirely (or almost) by directly reading the datastructures as they are laid on disk. As a result, the act of opening an indexing does not involve loading different datastructures from the disk into random access memory : starting a process, opening an index, and performing your first query can typically be done in a matter of milliseconds.
 
 This is an interesting property for a command line search engine, or for some multi-tenant log search engine : spawning a new process for each new query can be a perfectly sensible solution in some use case.
 
@@ -22,7 +22,6 @@ Of course this is crucial to reduce IO, and ensure that as much of our index can
 Also, whenever possible its data is accessed sequentially. Of course, this is an amazing property when tantivy needs to access the data from your spinning hard disk, but this is also
 critical for performance, if your data is read from and an `SSD` or even already in your pagecache.
 
-
 ## Segments, and the log method
 
 That kind of compact layout comes at one cost: it prevents our datastructures from being dynamic.
@@ -53,11 +52,7 @@ to get tantivy to fit your use case:
 
 *Example 2* You could also disable your merge policy and enforce daily segments. Removing data after one week can then be done very efficiently by just editing the `meta.json` and deleting the files associated to segment `D-7`.
 
-
-
-
-
-# Merging
+## Merging
 
 As you index more and more data, your index will accumulate more and more segments.
 Having a lot of small segments is not really optimal. There is a bit of redundancy in having
@@ -66,11 +61,7 @@ all these term dictionary. Also when searching, we will need to do term lookups
 That's where merging or compacting comes into place. Tantivy will continuously consider merge
 opportunities and start merging segments in the background.
 
-
-# Indexing throughput, number of indexing threads
-
-
-
+## Indexing throughput, number of indexing threads
 
 [^1]: This may eventually change.
 

doc/src/examples.md

@@ -1,3 +1,3 @@
 # Examples
 
-- [Basic search](/examples/basic_search.html)
+- [Basic search](/examples/basic_search.html)

doc/src/index_sorting.md

@@ -1,11 +1,11 @@
 
 - [Index Sorting](#index-sorting)
-    + [Why Sorting](#why-sorting)
-        * [Compression](#compression)
-        * [Top-N Optimization](#top-n-optimization)
-        * [Pruning](#pruning)
-        * [Other](#other)
-    + [Usage](#usage)
+  - [Why Sorting](#why-sorting)
+    - [Compression](#compression)
+    - [Top-N Optimization](#top-n-optimization)
+    - [Pruning](#pruning)
+    - [Other](#other)
+  - [Usage](#usage)
 
 # Index Sorting
 
@@ -15,32 +15,34 @@ Tantivy allows you to sort the index according to a property.
 
 Presorting an index has several advantages:
 
-###### Compression
+### Compression
 
-When data is sorted it is easier to compress the data. E.g. the numbers sequence [5, 2, 3, 1, 4] would be sorted to [1, 2, 3, 4, 5]. 
+When data is sorted it is easier to compress the data. E.g. the numbers sequence [5, 2, 3, 1, 4] would be sorted to [1, 2, 3, 4, 5].
 If we apply delta encoding this list would be unsorted [5, -3, 1, -2, 3] vs. [1, 1, 1, 1, 1].
-Compression ratio is mainly affected on the fast field of the sorted property, every thing else is likely unaffected. 
-###### Top-N Optimization
+Compression ratio is mainly affected on the fast field of the sorted property, every thing else is likely unaffected.
 
-When data is presorted by a field and search queries request sorting by the same field, we can leverage the natural order of the documents. 
+### Top-N Optimization
+
+When data is presorted by a field and search queries request sorting by the same field, we can leverage the natural order of the documents.
 E.g. if the data is sorted by timestamp and want the top n newest docs containing a term, we can simply leveraging the order of the docids.
 
 Note: Tantivy 0.16 does not do this optimization yet.
 
-###### Pruning
+### Pruning
 
 Let's say we want all documents and want to apply the filter `>= 2010-08-11`. When the data is sorted, we could make a lookup in the fast field to find the docid range and use this as the filter.
 
 Note: Tantivy 0.16 does not do this optimization yet.
 
-###### Other?
+### Other?
 
 In principle there are many algorithms possible that exploit the monotonically increasing nature. (aggregations maybe?)
 
 ## Usage
+
 The index sorting can be configured setting [`sort_by_field`](https://github.com/quickwit-oss/tantivy/blob/000d76b11a139a84b16b9b95060a1c93e8b9851c/src/core/index_meta.rs#L238) on `IndexSettings` and passing it to a `IndexBuilder`. As of Tantivy 0.16 only fast fields are allowed to be used.
 
-```
+```rust
 let settings = IndexSettings {
     sort_by_field: Some(IndexSortByField {
         field: "intval".to_string(),
@@ -58,4 +60,3 @@ let index = index_builder.create_in_ram().unwrap();
 Sorting an index is applied in the serialization step. In general there are two serialization steps: [Finishing a single segment](https://github.com/quickwit-oss/tantivy/blob/000d76b11a139a84b16b9b95060a1c93e8b9851c/src/indexer/segment_writer.rs#L338) and [merging multiple segments](https://github.com/quickwit-oss/tantivy/blob/000d76b11a139a84b16b9b95060a1c93e8b9851c/src/indexer/merger.rs#L1073).
 
 In both cases we generate a docid mapping reflecting the sort. This mapping is used when serializing the different components (doc store, fastfields, posting list, normfield, facets).
-

doc/src/json.md

@@ -21,16 +21,17 @@ For instance,  if user is a json field, the following document:
 ```
 
 emits the following tokens:
--  ("name", Text, "Paul")
--  ("name", Text, "Masurel")
--  ("address.city", Text, "Tokyo")
--  ("address.country", Text, "Japan")
--  ("created_at", Date, 15420648505)
 
+- ("name", Text, "Paul")
+- ("name", Text, "Masurel")
+- ("address.city", Text, "Tokyo")
+- ("address.country", Text, "Japan")
+- ("created_at", Date, 15420648505)
 
-# Bytes-encoding and lexicographical sort.
+## Bytes-encoding and lexicographical sort
 
 Like any other terms, these triplets are encoded into a binary format as follows.
+
 - `json_path`: the json path is a sequence of "segments". In the example above, `address.city`
 is just a debug representation of the json path `["address", "city"]`.
 Its representation is done by separating segments by a unicode char `\x01`, and ending the path by `\x00`.
@@ -41,16 +42,16 @@ This representation is designed to align the natural sort of Terms with the lexi
 of their binary representation (Tantivy's dictionary (whether fst or sstable) is sorted and does prefix encoding).
 
 In the example above, the terms will be sorted as
--  ("address.city", Text, "Tokyo")
--  ("address.country", Text, "Japan")
--  ("name", Text, "Masurel")
--  ("name", Text, "Paul")
--  ("created_at", Date, 15420648505)
+
+- ("address.city", Text, "Tokyo")
+- ("address.country", Text, "Japan")
+- ("name", Text, "Masurel")
+- ("name", Text, "Paul")
+- ("created_at", Date, 15420648505)
 
 As seen in "pitfalls", we may end up having to search for a value for a same path in several different fields. Putting the field code after the path makes it maximizes compression opportunities but also increases the chances for the two terms to end up in the actual same term dictionary block.
 
-
-# Pitfalls, limitation and corner cases.
+## Pitfalls, limitation and corner cases
 
 Json gives very little information about the type of the literals it stores.
 All numeric types end up mapped as a "Number" and there are no types for dates.
@@ -70,19 +71,21 @@ For instance, we do not even know if the type is a number or string based.
 
 So the query
 
-```
+```rust
 my_path.my_segment:233
 ```
 
 Will be interpreted as
-`(my_path.my_segment, String, 233) or (my_path.my_segment, u64, 233)`
+
+```rust
+(my_path.my_segment, String, 233) or (my_path.my_segment, u64, 233)
+```
 
 Likewise, we need to emit two tokens if the query contains an rfc3999 date.
 Indeed the date could have been actually a single token inside the text of a document at ingestion time. Generally speaking, we will always at least emit a string token in query parsing, and sometimes more.
 
 If one more json field is defined, things get even more complicated.
 
-
 ## Default json field
 
 If the schema contains a text field called "text" and a json field that is set as a default field:
@@ -96,11 +99,11 @@ This is a product decision.
 The user can still target the JSON field by specifying its name explicitly:
 `json_dynamic.text:hello`.
 
-## Range queries are not supported.
+## Range queries are not supported
 
 Json field do not support range queries.
 
-## Arrays do not work like nested object.
+## Arrays do not work like nested object
 
 If json object contains an array, a search query might return more documents
 than what might be expected.
@@ -120,9 +123,8 @@ Let's take an example.
 Despite the array structure, a document in tantivy is a bag of terms.
 The query:
 
-```
+```rust
 cart.product_type:sneakers AND cart.attributes.color:red
 ```
 
 Actually match the document above.
-

examples/custom_tokenizer.rs

@@ -50,7 +50,7 @@ fn main() -> tantivy::Result<()> {
     // for your unit tests... Or this example.
     let index = Index::create_in_ram(schema.clone());
 
-    // here we are registering our custome tokenizer
+    // here we are registering our custom tokenizer
     // this will store tokens of 3 characters each
     index
         .tokenizers()

fastfield_codecs/src/linearinterpol.rs

@@ -171,7 +171,7 @@ impl FastFieldCodecSerializer for LinearInterpolFastFieldSerializer {
         // On serialisation the offset is added to the actual value.
         // We need to make sure this won't run into overflow calculation issues.
         // For this we take the maximum theroretical offset and add this to the max value.
-        // If this doesn't overflow the algortihm should be fine
+        // If this doesn't overflow the algorithm should be fine
         let theorethical_maximum_offset = stats.max_value - stats.min_value;
         if stats
             .max_value

fastfield_codecs/src/multilinearinterpol.rs

@@ -29,7 +29,7 @@ pub struct MultiLinearInterpolFastFieldReader {
 
 #[derive(Clone, Debug, Default)]
 struct Function {
-    // The offset in the data is required, because we have diffrent bit_widths per block
+    // The offset in the data is required, because we have different bit_widths per block
     data_start_offset: u64,
     // start_pos in the block will be CHUNK_SIZE * BLOCK_NUM
     start_pos: u64,
@@ -300,7 +300,7 @@ impl FastFieldCodecSerializer for MultiLinearInterpolFastFieldSerializer {
         // On serialization the offset is added to the actual value.
         // We need to make sure this won't run into overflow calculation issues.
         // For this we take the maximum theroretical offset and add this to the max value.
-        // If this doesn't overflow the algortihm should be fine
+        // If this doesn't overflow the algorithm should be fine
         let theorethical_maximum_offset = stats.max_value - stats.min_value;
         if stats
             .max_value

ownedbytes/src/lib.rs

@@ -21,7 +21,7 @@ impl OwnedBytes {
         OwnedBytes::new(&[][..])
     }
 
-    /// Creates an `OwnedBytes` intance given a `StableDeref` object.
+    /// Creates an `OwnedBytes` instance given a `StableDeref` object.
     pub fn new<T: StableDeref + Deref<Target = [u8]> + 'static + Send + Sync>(
         data_holder: T,
     ) -> OwnedBytes {

query-grammar/src/query_grammar.rs

@@ -67,7 +67,7 @@ fn word<'a>() -> impl Parser<&'a str, Output = String> {
 /// 2021-04-13T19:46:26.266051969+00:00
 ///
 /// NOTE: also accepts 999999-99-99T99:99:99.266051969+99:99
-/// We delegate rejecting such invalid dates to the logical AST compuation code
+/// We delegate rejecting such invalid dates to the logical AST computation code
 /// which invokes time::OffsetDateTime::parse(..., &Rfc3339) on the value to actually parse
 /// it (instead of merely extracting the datetime value as string as done here).
 fn date_time<'a>() -> impl Parser<&'a str, Output = String> {

src/aggregation/agg_result.rs

@@ -57,7 +57,7 @@ impl AggregationResult {
         match self {
             AggregationResult::BucketResult(_bucket) => Err(TantivyError::InternalError(
                 "Tried to retrieve value from bucket aggregation. This is not supported and \
-                 should not happen during collection phase, but should be catched during \
+                 should not happen during collection phase, but should be caught during \
                  validation"
                     .to_string(),
             )),

src/aggregation/bucket/histogram/histogram.rs

@@ -70,7 +70,7 @@ pub struct HistogramAggregation {
     /// The interval to chunk your data range. Each bucket spans a value range of [0..interval).
     /// Must be a positive value.
     pub interval: f64,
-    /// Intervals implicitely defines an absolute grid of buckets `[interval * k, interval * (k +
+    /// Intervals implicitly defines an absolute grid of buckets `[interval * k, interval * (k +
     /// 1))`.
     ///
     /// Offset makes it possible to shift this grid into

src/aggregation/bucket/term_agg.rs

@@ -110,8 +110,8 @@ pub struct TermsAggregation {
     /// Set the order. `String` is here a target, which is either "_count", "_key", or the name of
     /// a metric sub_aggregation.
     ///
-    /// Single value metrics like average can be adressed by its name.
-    /// Multi value metrics like stats are required to adress their field by name e.g.
+    /// Single value metrics like average can be addressed by its name.
+    /// Multi value metrics like stats are required to address their field by name e.g.
     /// "stats.avg"
     ///
     /// Examples in JSON format:

src/aggregation/collector.rs

@@ -39,7 +39,7 @@ impl AggregationCollector {
 ///
 /// # Purpose
 /// AggregationCollector returns `IntermediateAggregationResults` and not the final
-/// `AggregationResults`, so that results from differenct indices can be merged and then converted
+/// `AggregationResults`, so that results from different indices can be merged and then converted
 /// into the final `AggregationResults` via the `into_final_result()` method.
 pub struct DistributedAggregationCollector {
     agg: Aggregations,

src/aggregation/intermediate_agg_result.rs

@@ -43,7 +43,7 @@ impl IntermediateAggregationResults {
     /// Convert intermediate result and its aggregation request to the final result.
     ///
     /// Internal function, AggregationsInternal is used instead Aggregations, which is optimized
-    /// for internal processing, by splitting metric and buckets into seperate groups.
+    /// for internal processing, by splitting metric and buckets into separate groups.
     pub(crate) fn into_final_bucket_result_internal(
         self,
         req: &AggregationsInternal,

src/collector/top_score_collector.rs

@@ -499,7 +499,7 @@ impl TopDocs {
     ///
     /// This method only makes it possible to compute the score from a given
     /// `DocId`, fastfield values for the doc and any information you could
-    /// have precomputed beforehands. It does not make it possible for instance
+    /// have precomputed beforehand. It does not make it possible for instance
     /// to compute something like TfIdf as it does not have access to the list of query
     /// terms present in the document, nor the term frequencies for the different terms.
     ///

src/core/index_meta.rs

@@ -311,7 +311,7 @@ pub struct IndexMeta {
     /// `IndexSettings` to configure index options.
     #[serde(default)]
     pub index_settings: IndexSettings,
-    /// List of `SegmentMeta` informations associated to each finalized segment of the index.
+    /// List of `SegmentMeta` information associated to each finalized segment of the index.
     pub segments: Vec<SegmentMeta>,
     /// Index `Schema`
     pub schema: Schema,

src/core/segment_id.rs

@@ -16,7 +16,7 @@ use uuid::Uuid;
 /// by a UUID which is used to prefix the filenames
 /// of all of the file associated with the segment.
 ///
-/// In unit test, for reproducability, the `SegmentId` are
+/// In unit test, for reproducibility, the `SegmentId` are
 /// simply generated in an autoincrement fashion.
 #[derive(Clone, Copy, PartialEq, Eq, Hash, Serialize, Deserialize)]
 pub struct SegmentId(Uuid);

src/directory/directory_lock.rs

@@ -45,7 +45,7 @@ pub static INDEX_WRITER_LOCK: Lazy<Lock> = Lazy::new(|| Lock {
 /// The meta lock file is here to protect the segment files being opened by
 /// `IndexReader::reload()` from being garbage collected.
 /// It makes it possible for another process to safely consume
-/// our index in-writing. Ideally, we may have prefered `RWLock` semantics
+/// our index in-writing. Ideally, we may have preferred `RWLock` semantics
 /// here, but it is difficult to achieve on Windows.
 ///
 /// Opening segment readers is a very fast process.

src/directory/file_slice.rs

@@ -112,7 +112,7 @@ impl FileSlice {
 
     /// Returns a `OwnedBytes` with all of the data in the `FileSlice`.
     ///
-    /// The behavior is strongly dependant on the implementation of the underlying
+    /// The behavior is strongly dependent on the implementation of the underlying
     /// `Directory` and the `FileSliceTrait` it creates.
     /// In particular, it is  up to the `Directory` implementation
     /// to handle caching if needed.

src/directory/managed_directory.rs

@@ -114,7 +114,7 @@ impl ManagedDirectory {
         let mut files_to_delete = vec![];
 
         // It is crucial to get the living files after acquiring the
-        // read lock of meta informations. That way, we
+        // read lock of meta information. That way, we
         // avoid the following scenario.
         //
         // 1) we get the list of living files.

src/directory/ram_directory.rs

@@ -40,7 +40,7 @@ impl Drop for VecWriter {
     fn drop(&mut self) {
         if !self.is_flushed {
             warn!(
-                "You forgot to flush {:?} before its writter got Drop. Do not rely on drop. This \
+                "You forgot to flush {:?} before its writer got Drop. Do not rely on drop. This \
                  also occurs when the indexer crashed, so you may want to check the logs for the \
                  root cause.",
                 self.path

src/directory/tests.rs

@@ -247,7 +247,7 @@ fn test_lock_blocking(directory: &dyn Directory) {
         //< lock_a_res is sent to the thread.
         in_thread_clone.store(true, SeqCst);
         let _just_sync = receiver.recv();
-        // explicitely dropping lock_a_res. It would have been sufficient to just force it
+        // explicitly dropping lock_a_res. It would have been sufficient to just force it
         // to be part of the move, but the intent seems clearer that way.
         drop(lock_a_res);
     });

src/fastfield/multivalued/reader.rs

@@ -55,7 +55,7 @@ impl<Item: FastValue> MultiValuedFastFieldReader<Item> {
     ///
     /// The min value does not take in account of possible
     /// deleted document, and should be considered as a lower bound
-    /// of the actual mimimum value.
+    /// of the actual minimum value.
     pub fn min_value(&self) -> Item {
         self.vals_reader.min_value()
     }

src/fastfield/reader.rs

@@ -49,7 +49,7 @@ pub trait FastFieldReader<Item: FastValue>: Clone {
     ///
     /// The min value does not take in account of possible
     /// deleted document, and should be considered as a lower bound
-    /// of the actual mimimum value.
+    /// of the actual minimum value.
     fn min_value(&self) -> Item;
 
     /// Returns the maximum value for this fast field.

src/fastfield/writer.rs

@@ -293,7 +293,7 @@ impl IntFastFieldWriter {
 
     /// Records a new value.
     ///
-    /// The n-th value being recorded is implicitely
+    /// The n-th value being recorded is implicitly
     /// associated to the document with the `DocId` n.
     /// (Well, `n-1` actually because of 0-indexing)
     pub fn add_val(&mut self, val: u64) {

src/indexer/index_writer.rs

@@ -31,7 +31,7 @@ pub const MARGIN_IN_BYTES: usize = 1_000_000;
 pub const MEMORY_ARENA_NUM_BYTES_MIN: usize = ((MARGIN_IN_BYTES as u32) * 3u32) as usize;
 pub const MEMORY_ARENA_NUM_BYTES_MAX: usize = u32::MAX as usize - MARGIN_IN_BYTES;
 
-// We impose the number of index writter thread to be at most this.
+// We impose the number of index writer thread to be at most this.
 pub const MAX_NUM_THREAD: usize = 8;
 
 // Add document will block if the number of docs waiting in the queue to be indexed
@@ -710,7 +710,7 @@ impl IndexWriter {
     }
 
     /// Runs a group of document operations ensuring that the operations are
-    /// assigned contigous u64 opstamps and that add operations of the same
+    /// assigned contiguous u64 opstamps and that add operations of the same
     /// group are flushed into the same segment.
     ///
     /// If the indexing pipeline is full, this call may block.

src/indexer/json_term_writer.rs

@@ -38,10 +38,10 @@ use crate::{DatePrecision, DateTime, DocId, Term};
 /// of values, with a position gap. Here we would like `The` and `Who` to get indexed at
 /// position 2 and 3 respectively.
 ///
-/// With regular fields, we sort the fields beforehands, so that all terms with the same
+/// With regular fields, we sort the fields beforehand, so that all terms with the same
 /// path are indexed consecutively.
 ///
-/// In JSON object, we do not have this confort, so we need to record these position offsets in
+/// In JSON object, we do not have this comfort, so we need to record these position offsets in
 /// a map.
 ///
 /// Note that using a single position for the entire object would not hurt correctness.

src/indexer/merge_policy.rs

@@ -43,7 +43,7 @@ pub mod tests {
 
     /// `MergePolicy` useful for test purposes.
     ///
-    /// Everytime there is more than one segment,
+    /// Every time there is more than one segment,
     /// it will suggest to merge them.
     #[derive(Debug, Clone)]
     pub struct MergeWheneverPossible;

src/indexer/merger.rs

@@ -545,7 +545,7 @@ impl IndexMerger {
 
         // copying into a temp vec is not ideal, but the fast field codec api requires random
         // access, which is used in the estimation. It's possible to 1. calculate random
-        // acccess on the fly or 2. change the codec api to make random access optional, but
+        // access on the fly or 2. change the codec api to make random access optional, but
         // they both have also major drawbacks.
 
         let mut offsets = Vec::with_capacity(doc_id_mapping.len());
@@ -606,7 +606,7 @@ impl IndexMerger {
         debug_time!("write-term-id-fast-field");
 
         // Multifastfield consists of 2 fastfields.
-        // The first serves as an index into the second one and is stricly increasing.
+        // The first serves as an index into the second one and is strictly increasing.
         // The second contains the actual values.
 
         // First we merge the idx fast field.
@@ -678,7 +678,7 @@ impl IndexMerger {
         doc_id_mapping: &SegmentDocIdMapping,
     ) -> crate::Result<()> {
         // Multifastfield consists in 2 fastfields.
-        // The first serves as an index into the second one and is stricly increasing.
+        // The first serves as an index into the second one and is strictly increasing.
         // The second contains the actual values.
 
         // First we merge the idx fast field.
@@ -739,7 +739,7 @@ impl IndexMerger {
         impl<'a> FastFieldDataAccess for SortedDocIdMultiValueAccessProvider<'a> {
             fn get_val(&self, pos: u64) -> u64 {
                 // use the offsets index to find the doc_id which will contain the position.
-                // the offsets are stricly increasing so we can do a simple search on it.
+                // the offsets are strictly increasing so we can do a simple search on it.
                 let new_doc_id = self
                     .offsets
                     .iter()
@@ -2078,7 +2078,7 @@ mod tests {
             let mut term_scorer = term_query
                 .specialized_weight(&searcher, true)?
                 .specialized_scorer(segment_reader, 1.0)?;
-            // the difference compared to before is instrinsic to the bm25 formula. no worries
+            // the difference compared to before is intrinsic to the bm25 formula. no worries
             // there.
             for doc in segment_reader.doc_ids_alive() {
                 assert_eq!(term_scorer.doc(), doc);
@@ -2103,7 +2103,7 @@ mod tests {
         let mut term_scorer = term_query
             .specialized_weight(&searcher, true)?
             .specialized_scorer(segment_reader, 1.0)?;
-        // the difference compared to before is instrinsic to the bm25 formula. no worries there.
+        // the difference compared to before is intrinsic to the bm25 formula. no worries there.
         for doc in segment_reader.doc_ids_alive() {
             assert_eq!(term_scorer.doc(), doc);
             assert_nearly_equals!(term_scorer.block_max_score(), 0.003478312);

src/indexer/segment_manager.rs

@@ -21,7 +21,7 @@ pub(crate) enum SegmentsStatus {
 }
 
 impl SegmentRegisters {
-    /// Check if all the segments are committed or uncommited.
+    /// Check if all the segments are committed or uncommitted.
     ///
     /// If some segment is missing or segments are in a different state (this should not happen
     /// if tantivy is used correctly), returns `None`.
@@ -168,8 +168,8 @@ impl SegmentManager {
                 segment_entries.push(segment_entry);
             }
         } else {
-            let error_msg = "Merge operation sent for segments that are not all uncommited or \
-                             commited."
+            let error_msg = "Merge operation sent for segments that are not all uncommitted or \
+                             committed."
                 .to_string();
             return Err(TantivyError::InvalidArgument(error_msg));
         }
@@ -182,7 +182,7 @@ impl SegmentManager {
     }
     // Replace a list of segments for their equivalent merged segment.
     //
-    // Returns true if these segments are committed, false if the merge segments are uncommited.
+    // Returns true if these segments are committed, false if the merge segments are uncommitted.
     pub(crate) fn end_merge(
         &self,
         before_merge_segment_ids: &[SegmentId],

src/indexer/segment_updater.rs

@@ -171,7 +171,7 @@ pub fn merge_indices<T: Into<Box<dyn Directory>>>(
     if indices.is_empty() {
         // If there are no indices to merge, there is no need to do anything.
         return Err(crate::TantivyError::InvalidArgument(
-            "No indices given to marge".to_string(),
+            "No indices given to merge".to_string(),
         ));
     }
 
@@ -219,7 +219,7 @@ pub fn merge_filtered_segments<T: Into<Box<dyn Directory>>>(
     if segments.is_empty() {
         // If there are no indices to merge, there is no need to do anything.
         return Err(crate::TantivyError::InvalidArgument(
-            "No segments given to marge".to_string(),
+            "No segments given to merge".to_string(),
         ));
     }
 
@@ -282,7 +282,7 @@ pub fn merge_filtered_segments<T: Into<Box<dyn Directory>>>(
 
 pub(crate) struct InnerSegmentUpdater {
     // we keep a copy of the current active IndexMeta to
-    // avoid loading the file everytime we need it in the
+    // avoid loading the file every time we need it in the
     // `SegmentUpdater`.
     //
     // This should be up to date as all update happen through
@@ -500,7 +500,7 @@ impl SegmentUpdater {
     // It returns an error if for some reason the merge operation could not be started.
     //
     // At this point an error is not necessarily the sign of a malfunction.
-    // (e.g. A rollback could have happened, between the instant when the merge operaiton was
+    // (e.g. A rollback could have happened, between the instant when the merge operation was
     // suggested and the moment when it ended up being executed.)
     //
     // `segment_ids` is required to be non-empty.

src/indexer/segment_writer.rs

@@ -53,7 +53,7 @@ fn remap_doc_opstamps(
 /// set of documents.
 ///
 /// They creates the postings list in anonymous memory.
-/// The segment is layed on disk when the segment gets `finalized`.
+/// The segment is laid on disk when the segment gets `finalized`.
 pub struct SegmentWriter {
     pub(crate) max_doc: DocId,
     pub(crate) ctx: IndexingContext,

src/postings/block_segment_postings.rs

@@ -199,7 +199,7 @@ impl BlockSegmentPostings {
         self.doc_decoder.output_array()
     }
 
-    /// Returns a full block, regardless of whetehr the block is complete or incomplete (
+    /// Returns a full block, regardless of whether the block is complete or incomplete (
     /// as it happens for the last block of the posting list).
     ///
     /// In the latter case, the block is guaranteed to be padded with the sentinel value:
@@ -494,7 +494,7 @@ mod tests {
         let schema = schema_builder.build();
         let index = Index::create_in_ram(schema);
         let mut index_writer = index.writer_for_tests()?;
-        // create two postings list, one containg even number,
+        // create two postings list, one containing even number,
         // the other containing odd numbers.
         for i in 0..6 {
             let doc = doc!(int_field=> (i % 2) as u64);

src/postings/mod.rs

@@ -500,7 +500,7 @@ pub mod tests {
         Ok(())
     }
 
-    /// Wraps a given docset, and forward alls call but the
+    /// Wraps a given docset, and forward all call but the
     /// `.skip_next(...)`. This is useful to test that a specialized
     /// implementation of `.skip_next(...)` is consistent
     /// with the default implementation.

src/postings/postings.rs

@@ -14,7 +14,7 @@ pub trait Postings: DocSet + 'static {
     /// The number of times the term appears in the document.
     fn term_freq(&self) -> u32;
 
-    /// Returns the positions offseted with a given value.
+    /// Returns the positions offsetted with a given value.
     /// The output vector will be resized to the `term_freq`.
     fn positions_with_offset(&mut self, offset: u32, output: &mut Vec<u32>);
 

src/postings/stacker/expull.rs

@@ -40,7 +40,7 @@ fn len_to_capacity(len: u32) -> CapacityResult {
 /// An exponential unrolled link.
 ///
 /// The use case is as follows. Tantivy's indexer conceptually acts like a
-/// `HashMap<Term, Vec<u32>>`. As we come accross a given term in document
+/// `HashMap<Term, Vec<u32>>`. As we come across a given term in document
 /// `D`, we lookup the term in the map and append the document id to its vector.
 ///
 /// The vector is then only read when it is serialized.

src/query/boolean_query/boolean_weight.rs

@@ -21,7 +21,7 @@ fn scorer_union<TScoreCombiner>(scorers: Vec<Box<dyn Scorer>>) -> SpecializedSco
 where TScoreCombiner: ScoreCombiner {
     assert!(!scorers.is_empty());
     if scorers.len() == 1 {
-        return SpecializedScorer::Other(scorers.into_iter().next().unwrap()); //< we checked the size beforehands
+        return SpecializedScorer::Other(scorers.into_iter().next().unwrap()); //< we checked the size beforehand
     }
 
     {

src/query/more_like_this/more_like_this.rs

@@ -139,7 +139,7 @@ impl MoreLikeThis {
     }
 
     /// Finds terms for a more-like-this query.
-    /// field_to_field_values is a mapping from field to possible values of taht field.
+    /// field_to_field_values is a mapping from field to possible values of that field.
     fn retrieve_terms_from_doc_fields(
         &self,
         searcher: &Searcher,

src/query/phrase_query/phrase_query.rs

@@ -68,7 +68,7 @@ impl PhraseQuery {
 
     /// Slop allowed for the phrase.
     ///
-    /// The query will match if its terms are seperated by `slop` terms at most.
+    /// The query will match if its terms are separated by `slop` terms at most.
     /// By default the slop is 0 meaning query terms need to be adjacent.  
     pub fn set_slop(&mut self, value: u32) {
         self.slop = value;

src/query/phrase_query/phrase_scorer.rs

@@ -428,7 +428,7 @@ mod tests {
     }
     #[test]
     fn test_slop() {
-        // The slop is not symetric. It does not allow for the phrase to be out of order.
+        // The slop is not symmetric. It does not allow for the phrase to be out of order.
         test_intersection_aux(&[1], &[2], &[2], 1);
         test_intersection_aux(&[1], &[3], &[], 1);
         test_intersection_aux(&[1], &[3], &[3], 2);

src/query/query_parser/query_parser.rs

@@ -577,7 +577,7 @@ impl QueryParser {
     /// object by naturally extending the json field name with a "." separated field_path
     /// - field_phrase: the phrase that is being searched.
     ///
-    /// The literal identifies the targetted field by a so-called *full field path*,
+    /// The literal identifies the targeted field by a so-called *full field path*,
     /// specified before the ":". (e.g. identity.username:fulmicoton).
     ///
     /// The way we split the full field path into (field_name, field_path) can be ambiguous,

src/query/union.rs

@@ -188,7 +188,7 @@ where
             });
 
             // at this point all of the docsets
-            // are positionned on a doc >= to the target.
+            // are positioned on a doc >= to the target.
             if !self.refill() {
                 self.doc = TERMINATED;
                 return TERMINATED;

src/reader/mod.rs

@@ -16,7 +16,7 @@ use crate::{Index, Inventory, Searcher, SegmentReader, TrackedObject};
 /// Defines when a new version of the index should be reloaded.
 ///
 /// Regardless of whether you search and index in the same process, tantivy does not necessarily
-/// reflects the change that are commited to your index. `ReloadPolicy` precisely helps you define
+/// reflects the change that are committed to your index. `ReloadPolicy` precisely helps you define
 /// when you want your index to be reloaded.
 #[derive(Clone, Copy)]
 pub enum ReloadPolicy {

src/schema/bytes_options.rs

@@ -13,7 +13,7 @@ pub struct BytesOptions {
     stored: bool,
 }
 
-/// For backward compability we add an intermediary to interpret the
+/// For backward compatibility we add an intermediary to interpret the
 /// lack of fieldnorms attribute as "true" if and only if indexed.
 ///
 /// (Downstream, for the moment, this attribute is not used if not indexed...)

src/schema/facet.rs

@@ -35,7 +35,7 @@ pub enum FacetParseError {
 /// have a `Facet` for `/electronics/tv_and_video/led_tv`.
 ///
 /// A document can be associated to any number of facets.
-/// The hierarchy implicitely imply that a document
+/// The hierarchy implicitly imply that a document
 /// belonging to a facet also belongs to the ancestor of
 /// its facet. In the example above, `/electronics/tv_and_video/`
 /// and `/electronics`.

src/schema/field_type.rs

@@ -139,7 +139,7 @@ pub enum FieldType {
     Bool(NumericOptions),
     /// Signed 64-bits Date 64 field type configuration,
     Date(DateOptions),
-    /// Hierachical Facet
+    /// Hierarchical Facet
     Facet(FacetOptions),
     /// Bytes (one per document)
     Bytes(BytesOptions),

src/schema/numeric_options.rs

@@ -32,7 +32,7 @@ pub struct NumericOptions {
     stored: bool,
 }
 
-/// For backward compability we add an intermediary to interpret the
+/// For backward compatibility we add an intermediary to interpret the
 /// lack of fieldnorms attribute as "true" if and only if indexed.
 ///
 /// (Downstream, for the moment, this attribute is not used anyway if not indexed...)

src/schema/term.rs

@@ -16,7 +16,7 @@ use crate::{DatePrecision, DateTime};
 /// If this is a JSON term, the type is the type of the leaf of the json.
 ///
 /// - <value> is,  if this is not the json term, a binary representation specific to the type.
-/// If it is a JSON Term, then it is preprended with the path that leads to this leaf value.
+/// If it is a JSON Term, then it is prepended with the path that leads to this leaf value.
 const FAST_VALUE_TERM_LEN: usize = 4 + 1 + 8;
 
 /// Separates the different segments of

src/schema/value.rs

@@ -418,7 +418,7 @@ mod binary_serialize {
                         _ => Err(io::Error::new(
                             io::ErrorKind::InvalidData,
                             format!(
-                                "No extened field type is associated with code {:?}",
+                                "No extended field type is associated with code {:?}",
                                 ext_type_code
                             ),
                         )),

src/snippet/mod.rs

@@ -50,7 +50,7 @@ impl FragmentCandidate {
 }
 
 /// `Snippet`
-/// Contains a fragment of a document, and some highlighed parts inside it.
+/// Contains a fragment of a document, and some highlighted parts inside it.
 #[derive(Debug)]
 pub struct Snippet {
     fragment: String,
@@ -97,7 +97,7 @@ impl Snippet {
         &self.fragment
     }
 
-    /// Returns a list of higlighted positions from the `Snippet`.
+    /// Returns a list of highlighted positions from the `Snippet`.
     pub fn highlighted(&self) -> &[Range<usize>] {
         &self.highlighted
     }

src/store/writer.rs

@@ -120,7 +120,7 @@ impl StoreWriter {
 
     /// Store a new document.
     ///
-    /// The document id is implicitely the current number
+    /// The document id is implicitly the current number
     /// of documents.
     pub fn store(&mut self, stored_document: &Document) -> io::Result<()> {
         self.intermediary_buffer.clear();
@@ -139,7 +139,7 @@ impl StoreWriter {
 
     /// Store bytes of a serialized document.
     ///
-    /// The document id is implicitely the current number
+    /// The document id is implicitly the current number
     /// of documents.
     pub fn store_bytes(&mut self, serialized_document: &[u8]) -> io::Result<()> {
         let doc_num_bytes = serialized_document.len();

src/termdict/fst_termdict/mod.rs

@@ -7,7 +7,7 @@
 //! For instance, in a dictionary containing the sorted terms "abba", "bjork", "blur" and "donovan",
 //! the `TermOrdinal` are respectively `0`, `1`, `2`, and `3`.
 //!
-//! For `u64`-terms, tantivy explicitely uses a `BigEndian` representation to ensure that the
+//! For `u64`-terms, tantivy explicitly uses a `BigEndian` representation to ensure that the
 //! lexicographical order matches the natural order of integers.
 //!
 //! `i64`-terms are transformed to `u64` using a continuous mapping `val ⟶ val - i64::MIN`

src/termdict/fst_termdict/streamer.rs

@@ -87,7 +87,7 @@ where A: Automaton
 {
     /// Advance position the stream on the next item.
     /// Before the first call to `.advance()`, the stream
-    /// is an unitialized state.
+    /// is an uninitialized state.
     pub fn advance(&mut self) -> bool {
         if let Some((term, term_ord)) = self.stream.next() {
             self.current_key.clear();

src/termdict/mod.rs

@@ -7,7 +7,7 @@
 //! For instance, in a dictionary containing the sorted terms "abba", "bjork", "blur" and "donovan",
 //! the [TermOrdinal] are respectively `0`, `1`, `2`, and `3`.
 //!
-//! For `u64`-terms, tantivy explicitely uses a `BigEndian` representation to ensure that the
+//! For `u64`-terms, tantivy explicitly uses a `BigEndian` representation to ensure that the
 //! lexicographical order matches the natural order of integers.
 //!
 //! `i64`-terms are transformed to `u64` using a continuous mapping `val ⟶ val - i64::MIN`

src/termdict/sstable_termdict/sstable/sstable_index.rs

@@ -35,7 +35,7 @@ pub struct BlockAddr {
 struct BlockMeta {
     /// Any byte string that is lexicographically greater or equal to
     /// the last key in the block,
-    /// and yet stricly smaller than the first key in the next block.
+    /// and yet strictly smaller than the first key in the next block.
     pub last_key_or_greater: Vec<u8>,
     pub block_addr: BlockAddr,
 }

src/termdict/sstable_termdict/streamer.rs

@@ -101,7 +101,7 @@ where
 {
     /// Advance position the stream on the next item.
     /// Before the first call to `.advance()`, the stream
-    /// is an unitialized state.
+    /// is an uninitialized state.
     pub fn advance(&mut self) -> bool {
         while self.delta_reader.advance().unwrap() {
             self.term_ord = Some(