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>
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>
Same per-caret gap as the argtextobj revert (VIM-4193): the new
TextObjectScope rangeProvider lambda has no way to read state for the
caret currently being iterated, so the post-migration version falls
back to withPrimaryCaret and breaks multi-caret ai/aI/ii.
Restore VimIndentObject.kt to its state just before a6db9acd7
("Refactor: Migrate VimIndentObject extension to new VimApi"), keeping
it on the old TextObjectActionHandler-based API until the new API
exposes a per-caret read primitive.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Pending a fix for the current-caret gap in the new TextObjectScope API
(VIM-4193): the rangeProvider lambda has no way to know which caret the
engine is currently iterating over, so the post-migration extension
falls back to withPrimaryCaret and breaks multi-caret daa/dia.
Restore VimArgTextObjExtension.kt to its state just before 86bf54d84
("Migrate argtextobj extension to new textObjects API"), keeping it on
the old TextObjectActionHandler-based API until the new API exposes a
per-caret read primitive.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
After the K3 coroutine audit made VimApi methods suspend,
these tests were not updated to wrap calls in runBlocking.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Part of the VimApi freeze decision (VIM-4161). Reverting the
partial migration to keep Exchange fully on the old API.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Replace RangeHighlighter field in Exchange with HighlightId. Use
injector.highlightingService for adding/removing highlights instead
of direct markupModel access. Update Util.clearExchange to take
VimEditor. Update test assertHighlighter to check markup model
directly (area validation lost — tracked with TODO).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The old condition `!isVisualLine && (hlArea == EXACT_RANGE || isVisual)`
was equivalent to `ex.type != LINE_WISE` because when !isVisualLine is
true, hlArea is always EXACT_RANGE, making the isVisual branch
unreachable. Pure logic simplification, no behavior change.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Replace separate nnoremap+nmap/putExtensionHandlerMapping+putKeyMappingIfMissing
with the combined nmapPluginAction/xmapPluginAction helpers for all four
mappings (cx, cxx, cxc, X). Remove ExchangeClearHandler and VExchangeHandler
classes; their logic is now in top-level bridge functions that still delegate
to the old Operator/Util code.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Preparation for new API migration: Exchange now stores startLine/startCol/
startOffset/endLine/endCol/endOffset directly, removing dependency on the
internal Mark type. All comparison and cursor logic updated accordingly.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Replace ExchangeHandler class with suspend fun VimApi.exchangeAction()
and register via initApi.mappings { nnoremap/nmap }.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
No behavior change — just switches from the old init() to
init(initApi) so we can incrementally migrate to the new API.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The command() handler now receives startLine and endLine (0-based)
from the resolved ex-command range. Previously the range was received
by the internal CommandAliasHandler but discarded before reaching the
plugin lambda.
Also fix using editor.projectId instead of the VimApiImpl's own
projectId, so the handler resolves the correct editor context.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Per VIM-4144 coroutine audit: methods inside non-locking scopes
(OptionScope, DigraphScope, OutputPanelScope) should be suspend
for RemDev future-proofing. Updated interfaces, implementations,
and extension functions.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Per VIM-4144 coroutine audit: read/change functions stay non-suspend
(Kotlin contracts don't support suspend, and they're already callable
from the suspend editor {} block). Block parameters stay non-suspend
(inside locks). Updated stale KDoc that referenced Deferred/Job.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Per VIM-4144 coroutine audit: handler lambdas should be suspend
for RemDev future-proofing. Implementation uses runBlocking bridge.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Per VIM-4144 coroutine audit: handler lambdas should be suspend
for RemDev future-proofing. Implementation uses runBlocking bridge.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Per VIM-4144 coroutine audit: handler lambdas should be suspend
for RemDev future-proofing. Also exposes command() at init time.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Per VIM-4144 coroutine audit: handler lambdas should be suspend
for RemDev future-proofing. Implementation uses runBlocking bridge.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Remove enterInsertMode(), enterNormalMode(), enterVisualMode() from VimApi.
Mode changes should use normal() — e.g., normal("<Esc>"), normal("i"),
normal("v") — matching how real Vim plugins handle mode transitions.
Neither Vim nor Neovim has a direct "set mode" API. All mode changes in
real plugins (surround, exchange, commentary, ReplaceWithRegister) use
normal!, feedkeys(), or :stopinsert. The removed methods used incomplete
internal delegation (changeMode Level 2) that skipped proper entry/exit
setup (marks, strokes, dot-repeat, document listeners).
Also removes the now-unused changeMode() function from Modes.kt.
See VIM-4143 for future proper mode-changing API design.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
After setAsCurrentWindow(), getSelectedTextEditor() returns stale data
because the platform propagates the change asynchronously via
flatMapLatest + stateIn, and there is no way to observe when
propagation completes.
Comment out window APIs in VimApi, VimApiImpl, CaretRead, CaretReadImpl.
Add limitation comment to VimWindowGroup. Update EditorContextTest to
call injector.window directly. Track re-enablement in VIM-4138.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Introduce VimInitApi as a restricted wrapper around VimApi that exposes
only init-safe methods (getVariable, mappings, textObjects,
exportOperatorFunction). During plugin init() there is no editor context,
so editor operations should not be callable. VimInitApi enforces this at
the type level via delegation rather than inheritance.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Verify that getSelectedEditor(projectId) correctly tracks the active
editor. After opening a new editor in a split window, VimApi's
editor { read { ... } } returns data from the newly selected editor.
Also update tasks.md: mark T005, T005b, T005c complete; drop T007,
T008 per VIM-4122 ADR; mark T009 as already done.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Use FileEditorManager's selected editor (internal model) instead of
focus-based detection. Falls back to injector.fallbackWindow when
projectId is null (init phase, project loading).
- Add getSelectedEditor(projectId) to VimEditorGroup interface
- Implement in EditorGroup.java using FileEditorManager
- Convert all thinapi scope impls from objects to classes accepting projectId
- Fix exportOperatorFunction to use execution-time editor.projectId
instead of init-time captured null
- Update all thinapi mock tests to mock fallbackWindow and restore
injector before tearDown
- Update CaretTransactionTest to use real projectId
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Add projectId to VimApiImpl and propagate through scope implementations.
This is a pre-refactoring step before switching from getFocusedEditor()
to getSelectedEditor() API.
- VimApiImpl: Add projectId parameter (nullable), with KDoc explaining
that it's null during init and falls back to fallback editor
- Scope implementations: Pass projectId through construction chain
- MappingScopeImpl, TextObjectScopeImpl: Get projectId from editor
at execution time via editor.projectId
- Tests: Pass null for projectId (no editor context in setup)
- Remove VimApi.kt extension function (no longer needed)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
- Add init(VimApi) experimental method to VimExtension interface
- Make init() a default empty method for backward compatibility
- Create VimApi in VimExtensionRegistrar and pass to extensions
- Migrate 7 extensions from api() to init(api: VimApi) pattern:
MiniAI, VimTextObjEntireExtension, VimIndentObject,
VimArgTextObjExtension, ParagraphMotion, ReplaceWithRegister
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
During macro execution, commands like <C-w>h can change the active
editor. Previously, the editor was captured once at macro start and
reused for all keystrokes, causing window-switching commands to
have no effect on subsequent operations.
Now we re-query FileEditorManager.selectedTextEditor on each keystroke
to get the currently selected editor.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
It's not necessary to explicitly catch the cancellation exception and return on that. Moreover, it's wrong not to re-throw the ProcessCanceledException
Decision: VimApi works in editor context only, not IDE-wide.
See YouTrack ADR for full rationale.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
New task to understand and document how to obtain editors reliably:
- Why focused approach is unreliable (global state, can change mid-op)
- Normal case: capture at shortcut entry point
- Edge cases: macros with :wincmd, API commands that switch windows
Renumbered all subsequent tasks (now 82 total).
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Swap K1 and K2 in Phase 2 tasks - editor context is more critical.
Add decision task T004 to define API scope (IDE-wide vs editor-only).
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Verified API module structure, documented VimApi interface methods,
and identified all VimExtensionFacade usages requiring migration.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
- Document TeamCity CI compatibility checker in spec, plan, and tasks
- Enhance T038 with specific Vimscript execution test cases
- Enhance T039 with specific variable scope test cases
- Add T043a for vim-engine separation verification
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
94 tasks organized by user story:
- US4 (API Finalization): 24 tasks for K1-K4 issues and G1-G4 gaps
- US1 (Complete API): 14 tasks for API module completeness
- US2 (Internal Migration): 24 tasks for built-in extension migrations
- US3 (External Experience): 18 tasks for documentation and external plugin PRs
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Add gg.ninetyfive, com.github.pooryam92.vimcoach, lazyideavim.whichkeylazy,
and com.github.vimkeysuggest to known plugins list and TeamCity compatibility job.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Feature branches SHOULD be used for development work
- Feature branches MUST be rebased to master frequently (e.g., daily)
- Update API layer spec and plan to use feature branch
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
- spec.md, plan.md: Change from feature branch to master (trunk-based)
- constitution.md: Expand branch selection guidelines
- Long-running features develop on master to avoid divergence
- Short-lived changes may use feature branches
- Planning must analyze scope to determine branch strategy
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Add Principle VIII: Trunk-Based Development
- Master branch as trunk, always release-ready
- Prefer direct commits to master when safe
- Feature branches for long-running work
- Rebase-only integration (no merge commits)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Clarifications from /speckit.clarify session:
- External plugins: Use list from doc/IdeaVim Plugins.md, re-research
before migration to ensure completeness
- Deprecation: No harsh deprecation; approach defined after successful
external plugin migrations
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Defines requirements for IdeaVim extension API layer:
- Complete API module exposing all extension functionality
- Internal plugin migration to validate API design
- External plugin support with team-provided migration PRs
- API safety (state updates, editor context, test accessibility)
Based on prior Mia API analysis and design decisions:
- XML-based extension registration (not @VimPlugin annotation)
- Listener/event API deferred to future version
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Added principles:
- V. External Contributors: Recognizes community contributions
- VI. Documentation Goals: Commits to improving code documentation
- VII. Architecture Decision Records: ADRs tracked in YouTrack
Expanded:
- IV. Code Quality Standards: Added commit clarity requirements
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Add general guidance for fixing flaky UI tests:
- Flaky = race condition, not timeout issue
- Wait for unique state identifiers, not shared elements
- Understand framework built-in waits (findText already waits)
- Trace causality backwards to find correct wait condition
- State transitions have intermediate states
These principles should improve autofix success rate for UI test failures.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Wait for "Action id copied" confirmation notification after clicking
"Copy Action Id". This ensures the clipboard was actually updated before
proceeding to paste, fixing the race condition where the test would
paste stale clipboard data.
The old wait for "Stop Tracking" was unreliable because that button
exists in both the old and new notifications during the transition.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Documents how to use the new IdeaVim extension API and how to
migrate existing extensions from VimExtensionFacade to the new
@VimPlugin annotation-based API.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Replace VimExtensionFacade.putExtensionHandlerMapping with the new
api.textObjects { register(...) } pattern. This simplifies the
extension by removing the ArgumentHandler class and its inner
ArgumentTextObjectHandler.
Key changes:
- Add LineInfoProvider interface to decouple ArgBoundsFinder from Document
- Create findArgumentRange extension function on VimApi
- Use api.textObjects { } for registering ia/aa text objects
- Remove unused imports and old handler code
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Add tests covering: change outer argument, single argument handling,
whitespace handling, cursor positioning, nested function calls,
quoted strings, multiline arguments, and various bracket types.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
UI tests were being skipped due to Gradle build cache restoring
previous results. This defeats the purpose of stability testing.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Claude AI should not be listed as a contributor. This removes the
entry and adds an exclusion to prevent it from being re-added.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Documents the approach for handling duplicate issues including:
- Choosing primary issues based on age and activity
- Protecting customer-tagged issues from duplication
- Avoiding duplication into closed issues
- Consolidating duplicates to a single primary
- Leaving courteous comments for reporters
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Document that each CI run should make only one logical change
to ensure granular, reviewable PRs. Multiple annotations can
only be grouped if they share the same reason and fix pattern.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Install Neovim in workflows that run tests:
- testsMaintenance.yml: deals with @TestWithoutNeovim annotations
- codebaseMaintenance.yml: can run gradle tests
- youtrackAutoAnalysis.yml: uses TDD for bug fixes and features
Also add guidance in testsMaintenance to verify actual Neovim behavior
when working with skip reasons, and allow nvim/echo bash commands.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Print "NEOVIM TESTING ENABLED" message when running tests with -Dnvim
flag so AI can verify Neovim testing is actually active.
Also fix skill documentation to use correct -Dnvim flag.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Similar to DIFFERENT, UNCLEAR is too vague and should be replaced
with a more specific reason after investigation.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Document the process for tests-maintenance skill:
1. Try removing annotation and running with Neovim first
2. If test passes, remove the outdated annotation
3. If test fails, replace with a more specific reason
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
- Change `test negative lookbehind regression` to use IDEAVIM_API_USED
(test uses internal search() helper that calls VimPlugin API directly)
- Remove outdated TestWithoutNeovim annotations from 5 tests that now
pass with Neovim: smartcase/ignorecase search tests
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
The clean task was invalidating the Gradle cache on each build,
making the caching feature ineffective.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
The relative paths .gradle/caches and .gradle/wrapper don't exist in the
checkout directory - Gradle stores caches in ~/.gradle/ by default.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Add --build-cache and --configuration-cache flags to all gradle steps
in ReleaseDev and ReleaseEap builds to match other build configurations.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Add disk space cleanup and reduce video recording size for Linux runners:
- Add "Free up disk space" step to remove .NET, Android SDK, GHC, CodeQL
- Reduce Xvfb resolution from 1920x1080 to 1280x720
- Optimize ffmpeg: 15fps, ultrafast preset, crf 28
This aligns with the existing Rider Linux workflow settings.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Replace UNCLEAR annotations with a properly documented reason explaining why backspace and other special keys fail in Neovim RPC testing. This makes the limitation clear for future developers and consolidates 8 tests under a single, well-explained reason.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
PyCharm now opens with a project directly instead of showing the Welcome Frame. Removed the project creation logic and unused imports.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
