The driver SDK's SelectionModel has no getSelectedText(Boolean) in 2025.3,
which broke the compilation of the ui-rd-tests module in the 2025.3 and
nvim jobs. Call it through our own remote interface instead.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Vim's `:help hist-names` lists "?" alongside "/" as an alias for the
search history, but getTypeByString only recognised "/". As a result,
histadd('?', ...), histdel('?'), histget('?') and histnr('?') failed
instead of operating on the search history.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
intellij.platform.rpc doesn't exist in 2025.3, is embedded in the core
classloader in 2026.1-2026.2 and is a standalone module since 2026.3.
Declaring it as a dependency of the embedded ideavim-common module disables
the whole plugin on 2025.3 and breaks the 2025.3 build.
Move the dependency to a new optional ideavim-rpc module that provides
VimRemoteApiResolver via the IdeaVIM.remoteApiResolver extension point.
When the module is skipped (2025.3), fall back to calling
RemoteApiProviderService from the core classloader.
For large files running search count blocked edt which caused IDE freezes.
Now we first try to quickly show coutn and if we are not able in given threshold move it to other thread and later on update UI accordingly.
Additionally added tests for large files
Adds a 2.46.1 section for the two fixes that went into the release (VIM-4310, VIM-4309), and documents the % register (VIM-1266) and the two g8 fixes under 2.47.0, the release they shipped in.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
findMatchingPairOnCurrentLine read the character at the caret offset
without checking that the current line has any characters. On an empty
document this indexed past the end of the text. An empty line has no
pair characters to match, so return no match there, as Vim does.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
determineSelectionType classified every range spanning more than one line as
line-wise. replaceText then built a line-wise VimSelection from it, which
expands to whole lines, so the text before startOffset on the first line and
after endOffset on the last one was silently discarded.
// "one two three\nfour five six\nseven eight"
replaceText(8, 18, "XXX") // "three\nfour"
// was: "XXX\nseven eight"
// expected: "one two XXX five six\nseven eight"
A multi-line range is now line-wise only when it actually covers those lines
completely, which is what ReplaceWithRegister's `2grr` needs; anything that
starts or ends mid-line stays character-wise and replaces exactly the
requested range.
This also drops the `isLine` check that the old code computed but could never
observe as true: it required the range to end with a line break while start
and end sat on the same line, and it was only consulted on the
startLine == endLine branch, where that cannot hold.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
CaretTransactionImpl declared its own getLineStartOffset, getLineEndOffset
and getLine, duplicating the implementations it already inherits through
`EditorAccessor by EditorAccessorImpl(projectId)`. The copies had drifted:
getLineEndOffset dropped the allowEnd argument and always called the
single-argument VimEditor.getLineEndOffset, so it behaved as allowEnd = true
regardless of what the caller asked for.
The visible effect is that the same EditorAccessor function disagrees with
itself depending on how deeply it is nested:
change {
getLineEndOffset(line, allowEnd = false) // last character
withPrimaryCaret { getLineEndOffset(line, allowEnd = false) } // line break
}
ReadScopeImpl and TransactionImpl both rely on the delegate, so dropping the
three redundant overrides fixes the argument handling and removes the
duplication that let them drift apart in the first place.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`isCommandHistoryWindow` used `Editor.getVirtualFile()`, which is not necessarily
populated while the editor is still being created - and that is exactly when it is
called, from `isAllowedFileEditor` via `vimDisabled`, to decide whether an editor
should be initialised. The command-line window opened by `q:`, `q/` and `q?` was
therefore classified as a non-Vim editor and `EditorListeners.add` never ran, so its
buffer never got its local option values.
Search count and search highlights are computed for the selected editor and for every
open editor, so searching for a pattern containing `\<` asked the cmdwin buffer for its
local 'iskeyword' and threw "Unexpected uninitialised buffer local value: iskeyword".
Resolve the file from the document instead, as every other check in `EditorHelper`
already does.
Found by the RandomActionsPropertyTest property tests.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`SliceFunctionTest` covered negative and out-of-range end indices, but
not an end index that resolves to zero, which is the boundary where the
exclusive end index of `slice()` and the inclusive end index of a sublist
expression disagree. Verified against the previous implementation: the
`end index of zero` cases fail (returning the whole collection), and the
negative cases that resolve to zero or below already passed.
Also pin the sublist side of that boundary: an explicit `-1` end index,
`-length` (first item only), and `-length - 1` (empty). These passed
before, and guard the shared `VimList.slice`/`VimString.substring`
against a regression in the other direction.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`VimList.slice` and `VimString.substring` treated an exclusive end index
of zero as "count from the end", i.e. as the size of the collection. That
convention exists only because `SublistExpression` has to convert Vim's
*inclusive* end index (which defaults to -1, the last item) into an
exclusive one, so `endInclusive + 1` legitimately produces zero for the
common `list[1:]` and `list[1:-1]` cases.
`slice()`, however, takes an end index that is already exclusive, so
`slice([1, 2, 3, 4, 5], 0, 0)` must be an empty list, and
`slice([1, 2, 3, 4, 5], 0, -5)` likewise resolves to an exclusive end of
zero. Both returned the entire collection instead. (See Vim's
`list_slice_or_index` / `eval_index_inner`, which decrement the end index
when it is exclusive and produce an empty result once it drops below
zero.)
Make the end index of `slice`/`substring` an unambiguous absolute index
and move the resolution of Vim's negative indices into the two call
sites, where the inclusive/exclusive distinction is known.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Tag stack entries keep the line number they were recorded with and are not
adjusted on edits. When that line no longer exists, :tags called
getLineText() with an out-of-range line and failed with
"Incorrect line: N, out of M". Show empty text for such entries instead.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
A search range consisting of a single delimiter made SearchAddress call
substring(1, 0), throwing StringIndexOutOfBoundsException. An empty
pattern now uses the last search pattern, as in Vim, and reports E35
when there is none.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
