This function was never used and will be superseded by
`RopeSliceExt::is_grapheme_boundary` (which accepts a byte index rather
than a character index) once we transition to Ropey v2. In the meantime
any callers should convert to byte index and use the `RopeSliceExt`
extension rather than form new dependencies on this.
This fixes a regression from the switch to tree-house with one of the
custom predicates in indent queries: `#not-kind-eq?`. This predicate
should be allowed to be written multiple times in a pattern. For example
in the Go indents:
; Switches and selects aren't indented, only their case bodies are.
; Outdent all closing braces except those closing switches or selects.
(
(_ "}" @outdent) @outer
(#not-kind-eq? @outer "select_statement")
(#not-kind-eq? @outer "type_switch_statement")
(#not-kind-eq? @outer "expression_switch_statement")
)
So instead of an `Option<T>` of one we need a `Vec<T>` and we need to
check that all of these predicates are individually satisfied (basically
`iter().all(/* node kind is not expected kind for that capture */)`).
This avoids using any custom configuration in a user-defined
`languages.toml` config for the syntax test cases. The test cases should
only use the builtin `languages.toml` config.
Also the xtask crate reimplemented `default_lang_loader` and
`default_lang_config`. These functions are replaced with calls into
`helix_core`.
`InactiveQueryCursor::new` might reuse a query cursor from a
thread-local cache if one is available, rather than create a new cursor.
Currently tree-house does not reset cached cursors back to defaults
(i.e. byte range and match limit). For now we can patch around this here
but eventually this should be fixed in `tree-house` upstream. Then this
patch can be reverted.
In practice this caused textobjects like `]f` to get "stuck" trying to
move to the next function if it was out of the current view. This is
because the highlight query cursor sets the range of the cursor to the
current viewport. We can reset the byte range to defaults to fix the
textobject behavior.
The switch to tree-house accidentally dropped some shebang parsing code
from the loader's function to detect by shebang. This change restores
that. The new code is slightly different as it's using a `regex_cursor`
regex on the Rope rather than eagerly converting the text to a
`Cow<str>` and running a regular regex across it.
This type also exists on `Editor`. This change brings it to the
`Document` as well because the replacement for `Syntax` in the child
commits will eliminate `Syntax`'s copy of `syn_loader`. `Syntax` will
also be responsible for returning the highlighter and query iterators
(which will borrow the loader), so the loader must be separated from
that type.
In the long run, when we make a larger refactor to have
`Document::apply` be a function of the `Editor` instead of the
`Document`, we will be able to drop this field on `Document` - it is
currently only necessary for `Document::apply`. Once we make that
refactor, we will be able to eliminate the surrounding `Arc` in
`Arc<ArcSwap<syntax::Loader>>` and use the `ArcSwap` directly instead.
This resolves a TODO in the core diagnostic module to refactor this
type. It was originally an alias of `LanguageServerId` for simplicity.
Refactoring as an enum is a necessary step towards introducing
"internal" diagnostics - diagnostics emitted by core features such as
a spell checker. Fully supporting this use-case will require further
larger changes to the diagnostic type, but the change to the provider
can be made first.
Note that `Copy` is not derived for `DiagnosticProvider` (as it was
previously because `LanguageServerId` is `Copy`). In the child commits
we will add the `identifier` used in LSP pull diagnostics which is a
string - not `Copy`.
Path completion items always have documentation but future core (i.e.
non-LSP) completions may not always have documentation - for example
word completion from the current buffer.
The `Name` variant's inner type can be switched to `RopeSlice` since
the parent commit removed the usage of `&str`. In doing this we need to
switch from a regular `Regex` to a `rope::Regex`, which is mostly a
matter of renaming the type.
The `Filename` and `Shebang` variants can also switch to `RopeSlice`
which avoids allocations in cases where the text doesn't reside on
different chunks of the rope. Previously `Filename`'s `Cow` was always
the owned variant because of the conversion to a `PathBuf`.
This splits the `InjectionLanguageMarker::Name` into two: one that
preforms the previous behavior (using the language configurations'
`injection_regex` fields and performing a match) and a new variant that
looks up directly by `language_id` with equality.
The old variant is used when capturing the injection language like we
do in the markdown queries for codefences. That captured text is part of
the document being highlighted so we might need a regex to recognize a
language like JavaScript as either "js" or "javascript". But the text
passed in the `(#set! injection.language "name")` property can be
looked up directly. This property is in the query code so there's no
need to be flexible in what we accept: we can require that the
`(#set! injection.language ..)` properties refer to languages by their
configured ID. This should save a noticeable amount of work for the
common case of injections: `(#set! injection.language)` is used much
more often than `@injection.language`.
The clippy version after the recent MSRV bump no longer emits
`redundant_clone` warnings for these lines. We allowed these previously
since they were emitted as false positives.
We clone this type very often in LSP pickers, for example diagnostics
and symbols. We can use a single Arc in many cases to avoid the
unnecessary clones.
The lsp location type has the lsp's URI type and a range. We can replace
that with a custom type private to the lsp commands module that uses the
core URI type instead.
We can't entirely replace the type with a new Location type in core.
That type might look like:
pub struct Location {
uri: crate::Uri,
range: crate::Range,
}
But we can't convert every `lsp::Location` to this type because for
definitions, references and diagnostics language servers send documents
which we haven't opened yet, so we don't have the information to convert
an `lsp::Range` (line+col) to a `helix_core::Range` (char indexing).
This cleans up the picker definitions in this file so that they can all
use helpers like `jump_to_location` and `location_to_file_location` for
the picker preview. It also removes the only use of the deprecated
`PathOrId::from_path_buf` function, allowing us to drop the owned
variant of that type in the child commit.
Whenever a document is changed helix maps various positions like the
cursor or diagnostics through the `ChangeSet` applied to the document.
Currently, this mapping handles replacements as follows:
* Move position to the left for `Assoc::Before` (start of selection)
* Move position to the right for `Assoc::After` (end of selection)
However, when text is exactly replaced this can produce weird results
where the cursor is moved when it shouldn't. For example if `foo` is
selected and a separate cursor is placed on each character (`s.<ret>`)
and the text is replaced (for example `rx`) then the cursors are moved
to the side instead of remaining in place.
This change adds a special case to the mapping code of replacements:
If the deleted and inserted text have the same (char) length then
the position is returned as if the replacement doesn't exist.
only keep selections invariant under replacement
Keeping selections unchanged if they are inside an exact replacement
is intuitive. However, for diagnostics this is not desirable as
helix would otherwise fail to remove diagnostics if replacing parts
of the document.
Pascal Kuthe
Michael Davis
Joffrey Bluthé
Rolo
Nik Revenco
Alexander Brassel
Niklas Wallgren
rhogenson
Kieran Moy
Philipp Mildenberger
spx01
TornaxO7
chtenb