Step 2/N of removing the octopus handler. Removes the flag and three
support files whose entire purpose was supporting the octopus migration.
- VimApplication interface: drop isOctopusEnabled() method.
- IjVimApplication: drop the override.
- VimEnterHandler.enableOctopus: now a const false, decoupled from the
deleted interface method. Octopus handler classes (still in this file)
continue to compile but early-return and pass through to nextHandler.
- Delete KeymapChecker.kt: checked that the keymap had Esc bound to
ACTION_EDITOR_ESCAPE because octopus owned EditorEscape. No longer
meaningful with VimShortcutKeyAction handling Esc directly.
- Delete CopilotKeymapCorrector.kt (VIM-3206): removed Copilot's Esc
shortcut because octopus intercepted EditorEscape. Rider / CLion Nova /
JBClient have run with octopus disabled for 14+ months without needing
this workaround.
- Delete EditorHandlersChainLogger.kt: debug logger for the
editorActionHandler chain, useful only during the octopus era.
- NotificationService / VimNotifications: drop notifyKeymapIssues (only
caller was KeymapChecker).
- VimListenerManager: drop correctorRequester / keyCheckRequests kicks
from turnOn / turnOff (flows lived inside the deleted files).
- IdeaVIM.ideavim-frontend.xml: remove postStartupActivity entries for
the three deleted classes and their keymap listener registrations.
Octopus handler classes in VimEnterHandler.kt and their XML registrations
are still present but now fully unreachable at runtime. They are removed
in subsequent steps.
Step 1/N of removing the octopus handler. With isOctopusEnabled()
hardcoded to false, the octopus branches in callers are unreachable.
This commit removes them, keeping only the non-octopus path.
- VimShortcutKeyAction: remove the early-return that skipped Enter/Esc
when octopus was active.
- KeyGroup / VimKeyGroupBase: always register Enter/Esc in
requiredShortcutKeys (the filter existed only to hand them to octopus).
- InsertEnterAction / SelectEnterAction: drop the forEachNativeCaret
branch that worked around IDEA-300030 inside the octopus chain; the
non-octopus processEnter(editor, context) call handles all carets.
- VimTestCase: dispatch Enter/Esc like any other key via
VimShortcutKeyAction.
- InsertEnterActionTest: remove per-repetition extension masking that
set up different octopus handler variants.
Octopus handler classes and their XML registrations are still present
but now unused; they are removed in subsequent steps.
Step 0/N of removing the octopus handler. Disables octopus at runtime
so subsequent steps can safely remove callers and handlers without
introducing a window where both octopus and VimShortcutKeyAction
compete for Enter/Esc.
The octopus handler chain remains registered but becomes a pass-through
(OctopusHandler.doExecute falls through to nextHandler when
isThisHandlerEnabled() returns false).
Use in-memory register when PRIMARY is unavailable due to wayland focus loss and bypass the live PRIMARY read during cisual paste to avoid automatic selection tracking overwriiting the yanked text
Plugin deactivate called fullReset() on the ex panel but left editor
mode and KeyHandlerState.commandLineCommandBuilder untouched. Since
KeyHandler is a singleton, the stale CMD_LINE builder survived a
plugin disable/enable cycle and matched LeaveCommandLineAction on the
next Esc, NPEing when the (already-deactivated) panel was unwrapped.
Call close() before fullReset() so mode, the key handler state, and
the panel are cleared together. Also replace the `!!` at the crash
site with a null-safe branch that logs VIM-4115 and clears the stale
builder, so any other producer of the same desync surfaces via a
Diogen report instead of a crash.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
in split mode/clion/ rider, after the comment action runs on rpc, it happens after removing selection. To fix that, we execute handler directly in synchronous way
After undoing a block-visual edit (<C-V>…x, <C-V>…c, <C-V>…I), IntelliJ restored the pre-edit multi-caret CaretState even though Vim is in single-cursor normal mode, leaving stray native carets. UndoRedoHelper now detects the 1 -> N caret jump across undo - a signal unique to block-visual since it's the only flow that collapses multi-carets on exit - and collapses back to a single caret at the block's top-left, matching Vim's convention
Accessing alias[0] without an isEmpty() guard crashed with
IndexOutOfBoundsException when the user typed a :command with only
-nargs specified but no command name (e.g. ":command -nargs=0").
After -nargs processing strips the flag, the remaining argument is
empty, so alias becomes "" and alias[0] throws. Adding alias.isEmpty()
guard treats the missing name as an invalid command name (E183).
Adds a regression test to ensure this case no longer crashes.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
The `isRegisterPending` field was not considered in several methods of
`CommandBuilder`, causing subtle bugs:
- `isEmpty` returned `true` while waiting for a register character
(after typing `"`), which caused `EditorResetConsumer` to treat the
partially-built command as if no command was in progress. This could
trigger an incorrect error indicator (beep) when pressing `<Esc>` to
cancel register selection in Normal mode, instead of silently resetting.
- `clone()` did not copy `isRegisterPending`, meaning a cloned builder
would lose pending register state. This is a latent bug affecting the
unused `AsyncKeyProcessBuilder`.
- `equals()` and `hashCode()` did not include `isRegisterPending`, so
two builders differing only in pending-register state were considered
equal, which is incorrect.
Add a regression test that verifies `isEmpty` returns `false` while a
register selection is pending, and `true` after cancelling with Escape.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Delayed extension init runs after .ideavimrc, so the plugin's default
`nmap gr`/`nmap grr`/`vmap gr` used to clobber user mappings. Switch to
`nmapPluginAction`/`vmapPluginAction` which guard on `hasmapto`, matching
the original Vim plugin's behavior.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Guard against VIM-4193 regressing again: both plugins are back on the
pre-migration TextObjectActionHandler API, so multi-caret daa/dia/dii
works today. If either plugin is re-migrated to the new TextObjectScope
API before it grows a per-caret read primitive (withCurrentCaret or
equivalent), these tests will fail loudly instead of the bug sneaking
through silently.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Alex Plate