Update documentation for emacs and split it for LSP-mode and Eglot
Emacs has now two LSP clients, the more minimalistic and lightweight [Eglot](https://joaotavora.github.io/eglot) and the extensive though a bit bloated [LSP Mode](https://github.com/emacs-lsp/lsp-mode). Eglot will soon be shipped with Emacs29. Both have rust-analyzer enabled by default and require no further setup other then being installed and enabled. `lsp-rust.el` is not required anymore.
The base-installation for each of those modes is so easy now that I don't think an enumerated list is necessary, both packages can be installed via the standard `M-x package-install` and the installation is a one-liner that I provide.
Configuration is only necessary for supporting the rust-analyzer extensions to the LSP protocol, which are built into LSP mode and require an [extension-package](https://github.com/nemethf/eglot-x) for Eglot.
But for further documentation, including the LSP extensions, I link against official documentation where possible to avoid duplicating efforts having to continually update this to stay up-to-date.
I rewrote most of the original emacs documentation, but the [linked blog](https://robert.kra.hn/posts/2021-02-07_rust-with-emacs/) post by `@rksm` seems still being actively updated with updates to LSP mode, so I kept the link. That blog post is opinionated, I personally use different packages which achieve similar end results (Eglot instead of LSP-mode, corfu instead of capf, vertico instead of helm etc.). But if someone doesn't already have an extensive Emacs configuration, I think this is not a bad starting point.
Disclaimer: I'm a Rust beginner, which is why I read the rust-analyzer setup docs. So I necessarily know how most Rust experts use Emacs. But I'm an experienced Emacs user who uses several other programming languages via LSP-mode support in Emacs. I used both, initially LSP-mode and recently migrated to Eglot.
Also I'm not an experienced in writing asciidoc and I didn't do a local test-built, hopefully the html builds in the way I imagine it. So I recommend to check that aspect of the PR. Maybe the documentation is in the CI build-artifacts?
This is a duplicate of a PR to the old rust-analyzer project https://github.com/rust-analyzer/rust-analyzer.github.io/pull/197, which I made because I didn't know that the documentation now lives here.
Emacs has now two LSP clients, the more minimalistic and lightweight Eglot and
the extensive though a bit bloated LSP-Mode. Eglot will soon be
shipped with Emacs29. Both have rust-analyzer enabled by default and require
no further setup then just being installed and enabled. `lsp-rust.el` is not
required anymore.
The base-installation for each of those modes is so easy now that I don't think
an enumerated list is necessary, both package can be installed via the standard
`M-x package-install` and the installation is a one-liner that I provide.
Configuration mostly comes into play for support the rust-analyzer extensions to
the LSP protocol, which are built into LSP mode and require an extension-package
for Eglot.
But for the configuration beyond the base configuration I link against official
documentation, quickstart guides and documentation for the lsp extensions, to
avoid showing outdated information here.
This commit is mostly a duplicate of a PR [1] that I made against the
rust-analyzer github project.
[1]: https://github.com/rust-analyzer/rust-analyzer.github.io/pull/197,
7ff0113006
Spelling: Space before version number in Emacs 29 in manual
Co-authored-by: Laurențiu Nicola <lnicola@users.noreply.github.com>
internal: remove `TypeWalk`
Because less code is better!
`hir_ty::TypeWalk` is only used in analysis-stats and its usage can be replaced by checking `TypeFlags` (which is precomputed upon `TyKind` interning so it should make analysis-stats a bit faster, though it was really negligible in my local environment).
We should just use chalk's `TypeVisitor` or `TypeFolder` instead even if we come to need it again.
Don't escape non-snippets in assist
I was misunderstanding that we're always sending snippets as response to assist request. For assists that never return snippets like `move_const_to_impl` we don't need to escape, and I don't think `utils::escape_non_snippet()` is useful at the moment since we guarantee that only a single edit will have `InsertTextFormat.Snippet` and we have `utils::render_snippet()` for that.
