4 files changed, 101 insertions, 57 deletions

diff --git a/docs/dev/README.md b/docs/dev/README.md
index 57162a47d..eab21a765 100644
--- a/docs/dev/README.md
+++ b/docs/dev/README.md
@@ -1,7 +1,7 @@
 # Contributing Quick Start
 
-Rust Analyzer is an ordinary Rust project, which is organized as a Cargo
-workspace, builds on stable and doesn't depend on C libraries. So, just
+Rust Analyzer is an ordinary Rust project, which is organized as a Cargo workspace, builds on stable and doesn't depend on C libraries.
+So, just
 
 ```
 $ cargo test
@@ -13,9 +13,8 @@ To learn more about how rust-analyzer works, see [./architecture.md](./architect
 It also explains the high-level layout of the source code.
 Do skim through that document.
 
-We also publish rustdoc docs to pages:
-
-https://rust-analyzer.github.io/rust-analyzer/ide/
+We also publish rustdoc docs to pages: https://rust-analyzer.github.io/rust-analyzer/ide/.
+Note though, that internal documentation is very incomplete.
 
 Various organizational and process issues are discussed in this document.
 
@@ -49,21 +48,28 @@ https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Fwg-rls-2.2E0
   Also a kind of fun.
   These issues should generally include a link to a Zulip discussion thread.
 
-# CI
+# Code Style & Review Process
+
+Do see [./style.md](./style.md).
 
-We use GitHub Actions for CI. Most of the things, including formatting, are checked by
-`cargo test` so, if `cargo test` passes locally, that's a good sign that CI will
-be green as well. The only exception is that some long-running tests are skipped locally by default.
+# Cookbook
+
+## CI
+
+We use GitHub Actions for CI.
+Most of the things, including formatting, are checked by `cargo test`.
+If `cargo test` passes locally, that's a good sign that CI will be green as well.
+The only exception is that some long-running tests are skipped locally by default.
 Use `env RUN_SLOW_TESTS=1 cargo test` to run the full suite.
 
 We use bors-ng to enforce the [not rocket science](https://graydon2.dreamwidth.org/1597.html) rule.
 
-# Launching rust-analyzer
+## Launching rust-analyzer
 
 Debugging the language server can be tricky.
 LSP is rather chatty, so driving it from the command line is not really feasible, driving it via VS Code requires interacting with two processes.
 
-For this reason, the best way to see how rust-analyzer works is to find a relevant test and execute it.
+For this reason, the best way to see how rust-analyzer works is to **find a relevant test and execute it**.
 VS Code & Emacs include an action for running a single test.
 
 Launching a VS Code instance with a locally built language server is also possible.
@@ -107,12 +113,7 @@ cd editors/code
 npm ci
 npm run lint
 ```
-
-# Code Style & Review Process
-
-Do see [./style.md](./style.md).
-
-# How to ...
+## How to ...
 
 * ... add an assist? [#7535](https://github.com/rust-analyzer/rust-analyzer/pull/7535)
 * ... add a new protocol extension? [#4569](https://github.com/rust-analyzer/rust-analyzer/pull/4569)
@@ -120,33 +121,30 @@ Do see [./style.md](./style.md).
 * ... add a new completion? [#6964](https://github.com/rust-analyzer/rust-analyzer/pull/6964)
 * ... allow new syntax in the parser? [#7338](https://github.com/rust-analyzer/rust-analyzer/pull/7338)
 
-# Logging
+## Logging
 
-Logging is done by both rust-analyzer and VS Code, so it might be tricky to
-figure out where logs go.
+Logging is done by both rust-analyzer and VS Code, so it might be tricky to figure out where logs go.
 
-Inside rust-analyzer, we use the standard `log` crate for logging, and
-`env_logger` for logging frontend. By default, log goes to stderr, but the
-stderr itself is processed by VS Code.
+Inside rust-analyzer, we use the standard `log` crate for logging, and `env_logger` for logging frontend.
+By default, log goes to stderr, but the stderr itself is processed by VS Code.
+`--log-file <PATH>` CLI argument allows logging to file.
 
-To see stderr in the running VS Code instance, go to the "Output" tab of the
-panel and select `rust-analyzer`. This shows `eprintln!` as well. Note that
-`stdout` is used for the actual protocol, so `println!` will break things.
+To see stderr in the running VS Code instance, go to the "Output" tab of the panel and select `rust-analyzer`.
+This shows `eprintln!` as well.
+Note that `stdout` is used for the actual protocol, so `println!` will break things.
 
 To log all communication between the server and the client, there are two choices:
 
-* you can log on the server side, by running something like
+* You can log on the server side, by running something like
   ```
   env RA_LOG=lsp_server=debug code .
   ```
-
-* you can log on the client side, by enabling `"rust-analyzer.trace.server":
-  "verbose"` workspace setting. These logs are shown in a separate tab in the
-  output and could be used with LSP inspector. Kudos to
-  [@DJMcNab](https://github.com/DJMcNab) for setting this awesome infra up!
+* You can log on the client side, by enabling `"rust-analyzer.trace.server": "verbose"` workspace setting.
+  These logs are shown in a separate tab in the output and could be used with LSP inspector.
+  Kudos to [@DJMcNab](https://github.com/DJMcNab) for setting this awesome infra up!
 
 
-There are also two VS Code commands which might be of interest:
+There are also several VS Code commands which might be of interest:
 
 * `Rust Analyzer: Status` shows some memory-usage statistics.
 
@@ -164,7 +162,7 @@ There are also two VS Code commands which might be of interest:
 
   ![demo](https://user-images.githubusercontent.com/36276403/78225773-6636a480-74d3-11ea-9d9f-1c9d42da03b0.png)
 
-# Profiling
+## Profiling
 
 We have a built-in hierarchical profiler, you can enable it by using `RA_PROFILE` env-var:
 
@@ -192,7 +190,9 @@ $ cargo run --release -p rust-analyzer -- analysis-bench ../chalk/ --highlight .
 $ cargo run --release -p rust-analyzer -- analysis-bench ../chalk/ --complete ../chalk/chalk-engine/src/logic.rs:94:0
 ```
 
-# Release Process
+Look for `fn benchmark_xxx` tests for a quick way to reproduce performance problems.
+
+## Release Process
 
 Release process is handled by `release`, `dist` and `promote` xtasks, `release` being the main one.
 
@@ -229,7 +229,7 @@ Make sure to remove the new changelog post created when running `cargo xtask rel
 We release "nightly" every night automatically and promote the latest nightly to "stable" manually, every week.
 We don't do "patch" releases, unless something truly egregious comes up.
 
-# Permissions
+## Permissions
 
 There are three sets of people with extra permissions:
 
diff --git a/docs/dev/lsp-extensions.md b/docs/dev/lsp-extensions.md
index 8a6f9f06e..73be59a82 100644
--- a/docs/dev/lsp-extensions.md
+++ b/docs/dev/lsp-extensions.md
@@ -602,8 +602,7 @@ interface TestInfo {
 
 This request is sent from client to server to move item under cursor or selection in some direction.
 
-**Method:** `experimental/moveItemUp`
-**Method:** `experimental/moveItemDown`
+**Method:** `experimental/moveItem`
 
 **Request:** `MoveItemParams`
 
diff --git a/docs/dev/style.md b/docs/dev/style.md
index e4a1672ca..48ce4b92a 100644
--- a/docs/dev/style.md
+++ b/docs/dev/style.md
@@ -55,9 +55,9 @@ https://www.tedinski.com/2018/02/06/system-boundaries.html
 We try to be very conservative with usage of crates.io dependencies.
 Don't use small "helper" crates (exception: `itertools` is allowed).
 If there's some general reusable bit of code you need, consider adding it to the `stdx` crate.
+A useful exercise is to read Cargo.lock and see if some of the *transitive* dependencies do not make sense for rust-analyzer.
 
-**Rationale:** keep compile times low, create ecosystem pressure for faster
-compiles, reduce the number of things which might break.
+**Rationale:** keep compile times low, create ecosystem pressure for faster compiles, reduce the number of things which might break.
 
 ## Commit Style
 
@@ -806,9 +806,67 @@ if let Some(expected_type) = ctx.expected_type.as_ref() {
 }
 ```
 
-**Rational:** `match` is almost always more compact.
+**Rationale:** `match` is almost always more compact.
 The `else` branch can get a more precise pattern: `None` or `Err(_)` instead of `_`.
 
+## Helper Functions
+
+Avoid creating singe-use helper functions:
+
+```rust
+// GOOD
+let buf = {
+    let mut buf = get_empty_buf(&mut arena);
+    buf.add_item(item);
+    buf
+};
+
+// BAD
+
+let buf = prepare_buf(&mut arena, item);
+
+...
+
+fn prepare_buf(arena: &mut Arena, item: Item) -> ItemBuf {
+    let mut res = get_empty_buf(&mut arena);
+    res.add_item(item);
+    res
+}
+```
+
+Exception: if you want to make use of `return` or `?`.
+
+**Rationale:** single-use functions change frequently, adding or removing parameters adds churn.
+A block serves just as well to delineate a bit of logic, but has access to all the context.
+Re-using originally single-purpose function often leads to bad coupling.
+
+## Helper Variables
+
+Introduce helper variables freely, especially for multiline conditions:
+
+```rust
+// GOOD
+let rustfmt_not_installed =
+    captured_stderr.contains("not installed") || captured_stderr.contains("not available");
+
+match output.status.code() {
+    Some(1) if !rustfmt_not_installed => Ok(None),
+    _ => Err(format_err!("rustfmt failed:\n{}", captured_stderr)),
+};
+
+// BAD
+match output.status.code() {
+    Some(1)
+        if !captured_stderr.contains("not installed")
+           && !captured_stderr.contains("not available") => Ok(None),
+    _ => Err(format_err!("rustfmt failed:\n{}", captured_stderr)),
+};
+```
+
+**Rationale:** like blocks, single-use variables are a cognitively cheap abstraction, as they have access to all the context.
+Extra variables help during debugging, they make it easy to print/view important intermediate results.
+Giving a name to a condition in `if` expression often improves clarity and leads to a nicer formatted code.
+
 ## Token names
 
 Use `T![foo]` instead of `SyntaxKind::FOO_KW`.
diff --git a/docs/user/manual.adoc b/docs/user/manual.adoc
index b1beeb883..e74b287fb 100644
--- a/docs/user/manual.adoc
+++ b/docs/user/manual.adoc
@@ -254,23 +254,10 @@ let g:LanguageClient_serverCommands = {
 
 ==== YouCompleteMe
 
-1. Install YouCompleteMe by following the instructions
-  https://github.com/ycm-core/lsp-examples#rust-rust-analyzer[here]
+Install YouCompleteMe by following the instructions
+  https://github.com/ycm-core/YouCompleteMe#installation[here].
 
-2. Configure by adding this to your vim/neovim config file (replacing the existing Rust-specific line if it exists):
-+
-[source,vim]
-----
-let g:ycm_language_server =
-\ [
-\   {
-\     'name': 'rust',
-\     'cmdline': ['rust-analyzer'],
-\     'filetypes': ['rust'],
-\     'project_root_files': ['Cargo.toml']
-\   }
-\ ]
-----
+rust-analyzer is the default in ycm, it should work out of the box.
 
 ==== ALE