From a514b5a72cf2a1c19ba6b6794e09b4386f4da2bb Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Yann=20C=C3=A9bron?= Date: Mon, 16 Mar 2015 22:06:51 +0100 Subject: [PATCH] [site] indexing_and_psi_stubs.md cleanup --- indexing_and_psi_stubs.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/indexing_and_psi_stubs.md b/indexing_and_psi_stubs.md index 56ffacc48..b45c9b741 100644 --- a/indexing_and_psi_stubs.md +++ b/indexing_and_psi_stubs.md @@ -11,7 +11,7 @@ INITIAL_SOURCE https://confluence.jetbrains.com/display/IDEADEV/Indexing+and+PSI ## Introduction -The indexing framework provides a quick way to locate certain elements (for example, files containing a certain word or methods with a particular name) in large code bases. Plugin developers can use the existing indexes built by IntelliJ IDEA itself, as well as build and use their own indexes. +The indexing framework provides a quick way to locate certain elements (for example, files containing a certain word or methods with a particular name) in large code bases. Plugin developers can use the existing indexes built by the IDE itself, as well as build and use their own indexes. It supports two main types of indexes: *file-based indexes* and *stub indexes*. File-based indexes are built directly over the content of files, and stub indexes are built over serialized *stub trees*. A stub tree for a source file is a subset of its PSI tree which contains only externally visible declarations and is serialized in a compact binary format. Querying a file-based index gets you the set of files matching a certain condition, and querying a stub index gets you the set of matching PSI elements. Therefore, custom language plugin developers should typically use stub indexes in their plugin implementations. @@ -31,7 +31,7 @@ The implementation contains of the following main parts: * `getIndexer()` returns the indexer class, which is responsible for actually building a set of key/value pairs based on the file content. -* `getKeyDescriptor()` returns the key descriptor, which is responsible for comparing the keys and storing them in a serialized binary format. Probably the most commonly used KeyDescriptor implementation is `EnumeratorStringDescriptor` implementation, designed for storing identifiers in an efficient way. +* `getKeyDescriptor()` returns the key descriptor, which is responsible for comparing the keys and storing them in a serialized binary format. Probably the most commonly used `KeyDescriptor` implementation is `EnumeratorStringDescriptor` implementation, designed for storing identifiers in an efficient way. * `getValueExternalizer()` returns the value serializer, which takes care of storing values in a serialized binary format.