Remove "Considerable Dimensions"

Moved to background

chapter/related-work.md

@@ -107,54 +107,7 @@ Microsoft's official website lists 172 implementations of the LSP[@implementatio
 An in-depth survey of these is outside the scope of this work.
 Yet, a few implementations stand out due to their sophisticate architecture, features, popularity or closeness to the presented work.
 
-### Considerable dimensions
-
-To be able to compare and describe LSP projects objectively and comprehensively, the focus will be on the following dimensions.
-
-Target Language
-  ~ The complexity of implementing language servers is influenced severely by the targeted language.
-    Feature rich languages naturally require more sophisticated solutions.
-    Yet, existing tooling can often be leveraged to facilitate language servers.
-
-Features
-  ~ The LSP defines an extensive array of capabilities.
-    The implementation of these protocol features is optional and servers and clients are able to communicate a set of *mutually supported* capabilities.
-  ~ The Langserver [@langserver.org] project identified six basic capabilities that are most widely supported:
-
-    1. Code completion,
-    2. Hover information,
-    3. Jump to definition,
-    4. Find references,
-    5. Workspace symbols,
-    6. Diagnostics
-
-  ~ Yet, not all of these are applicable in every case and some LSP implementations reach for a much more complete coverage of the protocol.
-
-File Processing
-  ~ Most language servers handling source code analysis in different ways.
-    The complexity of the language can be a main influence for the choice of the approach.
-    Distinctions appear in the way servers process *file indexes and changes* and how they respond to *requests*.
-  ~ The LSP supports sending updates in form of diffs of atomic changes and complete transmission of changed files.
-    The former requires incremental parsing and analysis, which are challenging to implement but make processing files much faster upon changes.
-    An incremental approach makes use of an internal representation of the source code that allows efficient updates upon small changes to the source file.
-
-    Additionally, to facilitate the parsing, an incremental approach must be able to provide a parser with the right context to correctly parse a changed fragment of code.
-   In practice, most language servers process file changes by re-indexing the entire file, discarding the previous internal state entirely.
-    This is a more approachable method, as it poses less requirements to the architects of the language server.
-    Yet, it is far less performant.
-    Unlike incremental processing (which updates only the affected portion of its internal structure), the smallest changes, including adding or removing lines effect the _reprocessing of the entire file_.
-    While sufficient for small languages and codebases, non-incremental processing quickly becomes a performance bottleneck.
-  ~ For code analysis LSP implementers have to decide between *lazy* or *greedy* approaches for processing files and answering requests.
-    Dominantly greedy implementations resolve most available information during the indexing of the file.
-    The server can then utilize this model to answer requests using mere lookups.
-    This stands in contrast to lazy approaches where only minimal local information is resolved during the indexing.
-    Requests invoke an ad-hoc resolution the results of which may be memoized for future requests.
-    Lazy resolution is more prevalent in conjunction with incremental indexing, since it further reduces the work associated with file changes.
-    This is essential in complex languages that would otherwise perform a great amount of redundant work.
-
-
-
-
+#
 ### Representative LSP Projects
 
 Since the number of implementations of the LSP is continuously growing, this thesis will present a selected set of notable projects.