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
Our pipeline could mark issues on youtrack as fixed even if they were not in release branch.
Added single script for all pipelines to deremine which commits enetered given release so changelog, whats new and release itself are using exactly same logic
Composed text from dead keys and input methods was inserted into the document and replaced the Visual selection before IdeaVim saw the key, so we now drop it in Normal, Visual and Operator-pending modes and only let the committed character through, like Vim in a terminal.
Commands describe themselves in @ExCommand/@CommandOrMotion, generateHelp renders the Vim-style help file and a workflow keeps it up to date on master.
In Rider actions like comment are async and afterActionPerformed happens right after action axecution without waiting for action to actually finish.
Which resulted in first normalizing carret by IdeaVim and then moving it by comment action in wrong place
To be vim compatible we need to wrap idea paste during replace mode.
Vim is pasting and replacing text and we were inserting it before cursor.
So to this we wrap paste action handler and in replace mode we handle it by ourselves
* VIM-1153 replay all keystrokes during .
we were storing actions and commands to replay during . repeat. Due to that we had to do a lot of strange logic to move cursor after ide chagnes. Becouse of that renaming tag element didn't work.
To make it work and more vim like we store real keystrokes and replay them
* VIM-1153 replay autocomplete
in new mechanism C-Y was working on active lookup and during replay there was no lookup. to fix that we go through action path which adds those keys by itself but we need to drop C-Y from RedoBuffer stack as it's replaved by actruall charachters
* VIM-1153 Fix other lookup actions
* VIM-1153 keep lookup commands as separate ones
Extracted all lookup commands as separate handlers as it was confusing to have seprate paths depending on isActiveLookup in handlers
`didAutoIndent` was set for `o`, `O` and Enter as well as for `cc` and `S`,
so leaving Insert mode without typing anything deleted the indent of a line
that had just been opened.
Vim does delete it, and it does so for an indent computed by 'indentexpr' or
'cindent' too (`fixthisline()` in indent.c). This is a deliberate difference:
in the IDE the indent comes from language support, and a line you have just
opened is expected to stay where it is. `cc` and `S` still follow Vim, since
there the line held text a moment ago and its leftover indent is noise.
* VIM-748 changing multiple commands with |
Added generic mechanism for chainging multiple commands with |
Main issue was with comamnds like `s` which might have | inside replaced regex
That's why we've adde whole machinery that split it in CommandVisitor.
We couldn't do it it antlr grammar itself as it would require having backwards state of grammer what antlr doesn't allow
* VIM-748 bump ksp version to 2.3.7
Vim computes 'hlsearch' per screen cell during redraw and keeps no highlight objects at all, while IdeaVim materialises a RangeHighlighter per match, so highlighting the whole buffer put tens of thousands of them in the markup model for the 35 lines the user can see.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Once the highlighters cover only the viewport they are no longer a complete model of the matches, so the two callers that read the match list back out of them need another source.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Nothing kept the vimLastHighlighters list and the markup model in step, and nothing could answer which part of the document is currently highlighted - both of which scoping the highlights to the viewport needs.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
When the selection is no longer ours but still holds our text minus the tail something reformatted away, the type now comes from what we published instead of being guessed from the text.
On Linux with clipboard=unnamed the `*` register is backed by the system PRIMARY selection, which stores text only, so its type was re-guessed from the text on every read. The selection can come back with trailing whitespace stripped, so a line-wise "foo \n" reads back as "foo" and gets downgraded to character-wise. We now reuse the text and type we published while we still own the selection, and only read and guess once another app claims it.
When user typed / twice in a row there could be race condition between deactivate and activate panel requesting focus. so becouse of focus parent in deactivate is asnyc it could happen after requestFocusInWindow in activate
JBR's WLClipboard takes Wayland-side primary ownership and Mutter's
Wayland→X11 bridge is racy under rapid visual selection, so external
readers (xclip, middle-click-paste) see stale content. Route PRIMARY
writes through xclip (preferred) or wl-copy (fallback) on Wayland,
deferred past IntelliJ's CaretModelImpl.updateSystemSelection
post-yank clobber. AWT path unchanged on X11/macOS/Windows.
1grzyb1