These come from Kakoune:
* '#' is the selection index register. It's read-only and produces the
selection index numbers, 1-indexed.
* '.' is the selection contents register. It is also read-only and
mirrors the contents of the current selections when read.
We switch the iterators returned from Selection's `fragments` and
`slices` methods to ExactSizeIterators because:
* The selection contents register can simply return the fragments
iterator.
* ExactSizeIterator is already implemented for iterators over Vecs, so
it's essentially free.
* The `len` method can be useful on its own.
This sets up a new Registers type that will allow us to expand support
for special registers. (See the child commits.)
We start simple with the regular (`Vec<String>`) registers and the
simplest special register, the black hole. In the child commits we
will expand these match arms with more special registers.
The upcoming special registers will need a few things that aren't
possible with the current Registers type in helix-core:
* Access to the `Editor`. This is only necessary when reading from
registers, so the `&Editor` parameter is only added to
`Registers::read`.
* Returning owned values. Registers in helix-core returns references
to the values backed by the `Vec<String>` but future special registers
will need to return owned values. We refactor the return value of the
read operations to give `Cow<str>`s and iterators over those.
* Returning a `Result` for write/push functions. This will be used by
the clipboard special registers.
Pascal and I discussed this and we think it's generally better to
take a 'RopeSlice' rather than a '&Rope'. The code block rendering
function in the markdown component module is a good example for how
this can be useful: we can remove an allocation of a rope and instead
directly turn a '&str' into a 'RopeSlice' which is very cheap.
A change to prefer 'RopeSlice' to '&Rope' whenever the rope isn't
modified would be nice, but it would be a very large diff (around 500+
500-). Starting off with just the syntax functions seems like a nice
middle-ground, and we can remove a Rope allocation because of it.
Co-authored-by: Pascal Kuthe <pascal.kuthe@semimod.de>
* Add initial support for LSP DidChangeWatchedFiles
* Move file event Handler to helix-lsp
* Simplify file event handling
* Refactor file event handling
* Block on future within LSP file event handler
* Fully qualify uses of the file_event::Handler type
* Rename ops field to options
* Revert newline removal from helix-view/Cargo.toml
* Ensure file event Handler is cleaned up when lsp client is shutdown
* _apply_motion generalization where possible
API encourages users to not forget setting `editor.last_motion` when
applying a motion. But also not setting `last_motion` without applying a
motion first.
* (rename) will_find_char -> find_char
method name makes it sound like it would be returning a boolean.
* use _apply_motion in find_char
Feature that falls out from this is that repetitions of t,T,f,F are
saved with the context extention/move and count. (Not defaulting to extend
by 1 count).
* Finalize apply_motion API
last_motion is now a private field and can only be set by calling
Editor.apply_motion(). Removing need (and possibility) of writing:
`motion(editor); editor.last_motion = motion`
Now it's just: `editor.apply_motion(motion)`
* editor.last_message: rm Box wrap around Arc
* Use pre-existing `Direction` rather than custom `SearchDirection`.
* `LastMotion` type alias for `Option<Arc<dyn Fn(&mut Editor)>>`
* Take motion rather than cloning it.
Co-authored-by: Michael Davis <mcarsondavis@gmail.com>
* last_motion as Option<Motion>.
* Use `Box` over `Arc` for `last_motion`.
---------
Co-authored-by: Michael Davis <mcarsondavis@gmail.com>
* correctly map unsorted positions
* Fix typo
Co-authored-by: Michael Davis <mcarsondavis@gmail.com>
---------
Co-authored-by: Michael Davis <mcarsondavis@gmail.com>
This resolves some confusing behavior where a scratch document created
by piping into hx is discarded when navigating away from that document.
We discard any scratch documents that are not modified and the original
`Editor::new_file_from_stdin` would create unmodified documents. We
refactor this function to create an empty document first and then to
apply the text from stdin as a change.
Does not change any behavior other than making the tuple slightly
more idiomatic. Keymap infobox shows key events, then the respective
description. This commit makes sure that order is used from the get go,
rather than flipping it midway.
* Add `helix_lsp::client::Client::supports_feature(&self, LanguageServerFeature)`
* Extend `doc.language_servers_with_feature` to use this method as filter as well
* Add macro `language_server_with_feature!` to reduce boilerplate for non-mergeable language server requests (like goto-definition)
* Refactored most of the `find_map` code to use the either the macro or filter directly via `doc.language_servers_with_feature`
Language Servers are now configured in a separate table in `languages.toml`:
```toml
[langauge-server.mylang-lsp]
command = "mylang-lsp"
args = ["--stdio"]
config = { provideFormatter = true }
[language-server.efm-lsp-prettier]
command = "efm-langserver"
[language-server.efm-lsp-prettier.config]
documentFormatting = true
languages = { typescript = [ { formatCommand ="prettier --stdin-filepath ${INPUT}", formatStdin = true } ] }
```
The language server for a language is configured like this (`typescript-language-server` is configured by default):
```toml
[[language]]
name = "typescript"
language-servers = [ { name = "efm-lsp-prettier", only-features = [ "format" ] }, "typescript-language-server" ]
```
or equivalent:
```toml
[[language]]
name = "typescript"
language-servers = [ { name = "typescript-language-server", except-features = [ "format" ] }, "efm-lsp-prettier" ]
```
Each requested LSP feature is priorized in the order of the `language-servers` array.
For example the first `goto-definition` supported language server (in this case `typescript-language-server`) will be taken for the relevant LSP request (command `goto_definition`).
If no `except-features` or `only-features` is given all features for the language server are enabled, as long as the language server supports these. If it doesn't the next language server which supports the feature is tried.
The list of supported features are:
- `format`
- `goto-definition`
- `goto-declaration`
- `goto-type-definition`
- `goto-reference`
- `goto-implementation`
- `signature-help`
- `hover`
- `document-highlight`
- `completion`
- `code-action`
- `workspace-command`
- `document-symbols`
- `workspace-symbols`
- `diagnostics`
- `rename-symbol`
- `inlay-hints`
Another side-effect/difference that comes with this PR, is that only one language server instance is started if different languages use the same language server.
When re requesting a completion that already has a selected item we
reuse that selections savepoint. However, the selection has likely
changed since that savepoint which requires us to use the selection
from that savepoint
