normally space is added by rider/clion backend which we cannot directlly execute as it is not running on JVM. Workaround is to specify space flag for comment handler
The agent has Xvfb installed but no X server is actually running on
:99, so the frontend IDE crashes at startup with
'Can't connect to X11 window server using :99'. Use `xvfb-run -a` to
spin up an Xvfb on a free display for the duration of the build, and
let it manage DISPLAY itself (drop the static env.DISPLAY=:99 param).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Xvfb is already running on the agent, so the build step doesn't need
to start it. Reduce the step to just the gradle invocation.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Xvfb is now installed on the TeamCity agent, so the VCS trigger and
the install step can be removed. Reverts the disable from 34196bc0d.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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 3/N of removing the octopus handler. Takes the 9 octopus handlers
out of IntelliJ's editorActionHandler chain for EditorEnter, EditorEscape,
EditorStartNewLine, and EditorStartNewLineBefore.
- IdeaVIM.ideavim-frontend.xml: remove registrations for VimEnterHandler,
CaretShapeEnterEditorHandler, VimEscHandler, VimEscLoggerHandler,
VimEnterLoggerHandler, StartNewLineDetector, StartNewLineBeforeCurrentDetector.
- IdeaVIM.ideavim-rider.xml and IdeaVIM.ideavim-clion-nova.xml: remove
Rider-specific VimEscForRiderHandler registration.
At this point Enter and Esc flow exclusively through VimShortcutKeyAction
(as they already did on Rider, CLion Nova, and JetBrains Client for the
last 14+ months). The handler classes themselves remain in
VimEnterHandler.kt as unreachable code; they are deleted in step 4.
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
