While it does give us a read-only abstraction over KeyMapping, it means we have two methods that do the same thing - getKeyMapping and getKeyMappingLayer without a clear indication of what the difference is. Furthermore, external usages only use getKeyMapping, and the layer isn't used at all.
GlobalCommand.globalExe had a try/catch/finally where the catch block only
re-threw the exception, which is unnecessary - finally executes regardless of
whether a catch is present. Remove the dead catch block.
Also fix a typo in SortCommandTest: "insensive" -> "insensitive".
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
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.
Previously we changed widget variables from vim variables to global one but those are not being persisted. We should not persist then so we've decided to persist them in `ModeWidgetSettings` and override if user will manually set global variable
The 262 EAP platform jars are compiled with -target 25 (bytecode
v69). The reified inline form EventFields.Enum<HandledModes>(name)
forces Kotlin to inline that platform bytecode into our :compileKotlin
output, which targets 21 (bytecode v65) and rejects the inline with:
Cannot inline bytecode built with JVM bytecode version 69 into
bytecode that is being built with JVM target 21.
Switch to the @JvmStatic @JvmOverloads overload that takes
Class<T> — same behavior (defaultEnumTransform), no inlining.
This is the only inline-reified call from EventFields in our codebase.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Implements g; and g, to walk through the per-buffer change list, mirroring Neovim's b_changelist semantics. The list is fed by the backend's RecentPlacesListener over an RPC topic (the same pattern as the existing jump service), so it works in both monolith and split mode.
There were race condition when user opened ex panel and after closing editor might be disposed for some reason which resulted in unhandled exception and complete loss of focus
Conventioal Commits plugin was replacing `Dummy.txt` commit window file with it's own. In this commit we redesign checking if editor is commit window by getting editor key for commit window
Step 5/N of removing the octopus handler. Cleanup pass over build config,
CI workflows, and stale comments. No runtime behavior change.
- build.gradle.kts: drop systemProperty("octopus.handler", ...) from
runIde, runPycharm, runWebstorm, runClion, and runIdeForUiTests.
The runIde { } block becomes empty and is removed entirely.
- Delete .github/workflows/runUiOctopusTests.yml: this workflow ran the
UI test suite with -Doctopus.handler=false to verify behavior without
octopus. That is now the only behavior, so the workflow is redundant
with runUiTestsIJ.yml.
- IdeaSpecifics.LookupTopicListener and RiderEscLookupListener: update
comments that justified Rider/CLion Nova-specific handling as "octopus
is disabled (VIM-3815)". The actual reason is unrelated to octopus:
these IDEs' popup manager consumes Escape before the action system
runs. The Rider/CLion Nova gating remains correct.
Step 4/N of removing the octopus handler. Deletes the file that held
all octopus infrastructure (both abstract base and the concrete
handlers). Its XML registrations were removed in step 3, so the classes
had been unreachable code.
- Delete VimEnterHandler.kt entirely: OctopusHandler, VimKeyHandler,
VimEnterHandler, VimEscHandler, VimEscForRiderHandler,
VimEscLoggerHandler, VimEnterLoggerHandler, CaretShapeEnterEditorHandler,
StartNewLineDetector, StartNewLineBeforeCurrentDetector,
isOctopusEnabled(KeyStroke, Editor), enableOctopus, commandContinuation.
- ChangeGroup.processEnter(editor, caret, context): delete. It existed
only to continue execution into the next octopus EditorActionHandler
via commandContinuation when inside the octopus chain. With octopus
gone, InsertEnterAction and SelectEnterAction call the editor-level
processEnter(editor, context) which dispatches through the IJ action
system as usual.
- VimChangeGroup: drop the per-caret processEnter declaration.
- InsertEnterActionTest: drop the @BeforeEach that set up three octopus
handler variants via ExtensionTestUtil.maskExtensions (existed to test
around IDEA-300030). Convert @RepeatedTest(3) to @Test - there are no
longer three configurations to exercise.
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).
grzybek