Moves the Area field agent from the JetBrains/vim-claude-robot repository
into this one, where the YouTrack tooling and the Claude proxy setup
already exist.
The previous agent passed a single prompt to `claude -p` with the ticket
summary, the ticket description, and the list of Area values. It had no
tools, so it could not read the ticket comments, see how an Area value is
used on other tickets, or look at the source. The new workflow runs an
agent that reads the ticket, searches comparable tickets when the right
value is not obvious, and greps the code when the ticket names a command
or an option.
A script selects the ticket, so a run with nothing to triage ends before
the agent starts.
Add to the YouTrack tools:
- searchTickets, which reports the Area values of the tickets it finds
- getAreaValues and setArea, which reject unknown value names before
writing and verify the field afterwards
- setTagByName, so a tag no longer needs a hardcoded id
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
MotionGroup.getMotionRange2 is a copy of VimMotionGroupBase.getMotionRange
that OperatorAction uses for g@, so every operatorfunc based operator - the
Commentary and Surround extensions, and any <Plug> operator - missed the two
range fixes of this branch. `gc}` commented one line more than `d}` deleted,
and `g@w` on the last character of the file did nothing.
Port the ':help exclusive' end adjustment and the end of file clamp, and
cover both with tests that exercise g@.
Also fixes the count for the inner quote text objects: Vim guards the
adjustment with "count < 2" in current_quote(), so any count of 2 or more
includes the quotes, not just exactly 2 (VIM-4163).
:help v_iquote - "Special case: With a count of 2 the quotes are included,
but no extra white space as with a"/a'/a`".
The count was passed to the text object handlers and then dropped, so `2i"`
behaved exactly like `i"` and left the quotes behind.
:help :s_flags - "n: Report the number of matches, do not actually
substitute". The flag was accepted and then ignored, so `:%s/a/b/n`
performed the substitution instead of counting.
The matches are counted the same way that they would be substituted, so
without the 'g' flag only the first match of each line counts, and the 'c'
flag is ignored.
The undocumented vi feature that the code already describes - ":s\/sub/"
and ":s\?sub?" reuse the last search pattern, ":s\&sub&" reuses the last
substitute pattern - never worked. The branch that parses the backslash
delimiter left the pattern as the empty string instead of clearing it, so
the block that reuses the last pattern was skipped and the empty string was
compiled as a regex, failing with E383.
The two error messages of that block were also the wrong way round: a
missing search pattern is E35 and a missing substitute pattern is E33, as
they already are in Address.
A look behind matches when its pattern ends exactly where the look behind
started. The simulation of the assertion returned as soon as it reached the
accept state, and the caller then compared that one result against the
current index, so the alternatives that were still on the stack were thrown
away.
With `\%(a\|ab\)\@<=c` on "abc" the shorter alternative was found first,
ended at the wrong index, and the whole start position was rejected, so the
positive assertion did not match and the negative one wrongly did.
The simulation now takes an optional target index. Reaching the accept state
at another index no longer stops it, so every way the pattern can match is
tried. Only the look behind passes a target index, so nothing else changes.
The backtracking simulation applied the captures of every state it visited
directly to the shared capture group collection and never undid them, so
what a failed branch captured leaked into the branch that did match.
For \zs, that moved the start of the match: `a\zsc\|ab` matched "b" instead
of "ab", because the first branch set the start of the match before failing.
Fix(VIM-4297): the same leak through \ze force ended the match. `a\zec\|ab`
matched "a" instead of "ab", because the force ended flag of the failed
branch made the end capture of the matching branch be ignored.
The capture group collection can now take and restore a snapshot of itself,
and counts its own changes. Each frame of the simulation stack remembers
that count, and every capture pushes a snapshot, so popping a frame can undo
everything that the branches explored since have captured. The stack is
shared with the nested simulations of assertions, and an assertion that does
not contribute to the match undoes its captures too.
Vim applies 'ignorecase' and \c to the individual characters and to the
ranges of a collection, but never to a character class, so \c[[:upper:]]
does not match a lowercase character.
The matcher tested the class against both the lowercase and the uppercase
variant of the character, which made \c[[:upper:]] match every letter.
:help aquote - any trailing white space is included, unless there is none,
then leading white space is included. Vim's in_quote uses vim_iswhite, which
matches a space or a tab, but IdeaVim only looked for a space.
With a tab after the closing quote, `da"` found no trailing white space and
fell back to including the leading space, deleting the wrong text.
Char.isWhitespace() is deliberately not used, because it also matches a new
line, which would let the scan leave the line.
For a file that ends with a new line, the IDE shows an extra empty last
line. Vim has no such line - the new line is just the last line's EOL.
findSentenceStart() treated that line as a paragraph boundary and returned
its offset, which is the size of the file, so `)` on the last sentence put
the caret on a position that does not exist in Vim, and `d)` deleted the
trailing new line along with the sentence.
Clamp the paragraph offset to the last character of the file. The clamp is
applied in findSentenceStart() rather than in findNextParagraph(), because
findSentenceEnd() relies on comparing its result against the file size when
the last sentence has no terminating punctuation.
'iskeyword' only applies to Latin-1 characters. Vim classifies everything
above with a fixed table of character classes and treats a character as a
word character when its class is greater than punctuation (vim_iswordc_buf
and utf_class_buf in mbyte.c).
IdeaVim treated every character above U+00FF as a keyword character, so word
motions never stopped at non-ASCII punctuation: `w` on "foo—bar" skipped the
whole run, and `2e` on "です。next" jumped past the ideographic full stop.
Port Vim's table of blank and punctuation intervals. 'isfname' keeps
treating every multibyte character as a filename character, which is what
vim_isfilec does.
Vim's forward word motions fail at the end of the file, but `nv_wordcmd`
only reports the failure when no operator is pending. With an operator, the
operator is applied from the caret to the end of the file, so `dw` on the
last character of the file deletes that character.
IdeaVim returned Motion.Error in both cases, and getMotionRange() aborted
the operator, so `dw`, `dW` and `de` on the last character of the file did
nothing at all.
Forward word motions now opt in to clamping the failed motion to the end of
the file, which getMotionRange() (only ever called with a pending operator)
applies. Plain `w` in normal mode still beeps, and the backward motions `b`,
`ge` and `gE` are unchanged - Vim beeps for those even with an operator.
:help exclusive - when an exclusive motion ends in column 1, its end moves
to the end of the previous line and the motion becomes inclusive. Only the
second half of the rule (the motion becomes linewise when the start is at or
before the first non-blank) was implemented, in the delete and yank
operators.
Without the first half, d} from the middle of a paragraph deleted the new
line of the last line of the paragraph too, merging away the blank line that
separates the paragraphs, and y} yanked a trailing new line that Vim does
not yank.
The operators recognise the linewise half of the rule by the end of the
range being in column 1, so the end is only adjusted when the start is not
in the indent, which is exactly when Vim makes the motion inclusive instead
of linewise.
Backward motions are left alone. Vim opts the affected ones out explicitly,
e.g. <BS> and h wrapping to the previous line set CA_NO_ADJ_OP_END.
anyNonWhitespace() coerced the end of its backward scan to 0, so at offset 0
the range 0..0 inspected the character *under* the caret instead of being
empty. The caller then believed there was non-blank text before the range
start and skipped Vim's charwise-to-linewise promotion for exclusive
motions, but only at the very first character of the file.
Dropping the coercion leaves an empty 0..-1 range, matching what already
happens at every other line-start offset.
A WORD is a sequence of non-blank characters, separated with white space
(:help WORD). Vim's cls() returns the same class for every non-blank
character when cls_bigword is set, so a change of Unicode script must not
end a WORD.
charType() consulted the Hiragana/Katakana/CJK Unicode blocks before the
punctuationAsLetters (bigWord) flag, so W, E, B and dW stopped at the
boundary between scripts: E on "abcあいう def" landed on 'c' instead of 'う'.
Short-circuit on punctuationAsLetters before the script checks. The script
classes still apply to small-word motions, which is where they belong.
Replace the scripts:eapReleaseActions Gradle/Kotlin task with a tsx
implementation wired into the EAP release pipeline as a script step.
Behavior is unchanged: Ready To Release tickets not yet tagged as
released in EAP get the tag plus the EAP-availability comment.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
findAll silently ignored its ignoreCase parameter and re-derived case
sensitivity from the global smartcase/ignorecase options. As a result,
using * on a capitalized word with 'smartcase' enabled performed a
case-insensitive search but highlighted only the case-sensitive matches.
findAll now honors an explicit ignoreCase request: smartcase is skipped
and ignorecase is forced when the caller has already resolved case
handling. Behavior is unchanged when ignoreCase is false, so existing
callers are unaffected.
Cherry-picked from #1466 by davidot.
`build.gradle.kts` `changeNotes` is now auto-derived from CHANGES.md at
build time via the org.jetbrains.changelog plugin, so the skill and the
claude-code-review workflow note no longer need to mention syncing it
by hand.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Replaces the 30-line hardcoded HTML block with a provider that renders
the matching section from CHANGES.md via the org.jetbrains.changelog
plugin (already configured). Falls back to the latest released section
during dev / SNAPSHOT builds, so patchPluginXml always produces sensible
output.
After this lands, releases no longer need a manual sync of changeNotes
against CHANGES.md — the TS promoter that runs earlier in the pipeline
is the single source of truth.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
These were disabled in TeamCity since well before 2.29.0 and the TS
promoter wired in the previous commit takes over their responsibilities.
JGit stays as a dependency — still used by addReleaseTag.kt,
selectBranch.kt, calculateNewDevVersion.kt, and util.kt.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Replaces the long-disabled Kotlin changelogUpdateUnreleased/commitChanges
gradle steps with a new TS CLI (scripts-ts/src/promoteChangelog.ts) plus
two TC script steps:
* "Update change log" + "Commit preparation changes" — run on the
release branch before tagging, so the release tag points at the
promoted CHANGES.md commit.
* "Sync changelog to master" — runs after publish to mirror the
promotion on master. Master push is soft-fail so an upstream race
with the daily cron doesn't sink the marketplace release.
The promoter is a pure function (replace `## [To Be Released]` →
`## X.Y.Z, YYYY-MM-DD` for major/minor; no-op for patch releases per
the project convention that patches roll into the parent minor). Ten
vitest tests cover the behavior. CLI wrapper handles the TC entrypoint.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The probe served its diagnostic purpose: confirmed Node 22.18.0 / npm
10.9.3 / npx are available on the release-class Linux agent via nvm.
With that question answered, the build type is no longer useful.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
One-shot diagnostic build before wiring scripts-ts CLIs (the new
promoteChangelog.ts) into the release pipeline. Runs on the same
agent requirements as ReleasePlugin (Linux, MEDIUM CPU) and prints
node/npm/npx availability and PATH. No triggers — run manually.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The "To Be Released" section had accumulated everything from 2.29.0
through 2.35.x because the release pipeline's promoter step was
disabled in TC and the YouTrack ticket update step was broken (fixed
in 13b6a9ff9). Bucketed each entry to the release that first shipped
the change, using PR merge commits and git tag containment.
Per the project convention, patch releases roll into their parent
minor; 2.31.x is folded into 2.32.0 since 2.31.0 was unlisted on the
marketplace. 2.34.0 gets its own section noting it is a re-release
of 2.33.0 (same commit). VIM-3948 (Full IDE integration epic) is
excluded per the changelog skill's Vim Everywhere rule.
build.gradle.kts changeNotes synced to the 2.35.0 section.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Commit a1e5b6788 switched getYoutrackTicketsByQuery to ktor's
parameter() helper, which URL-encodes its value. The two release
call sites still passed pre-encoded queries, so they were encoded
again and YouTrack searched for the literal "%23{Ready To Release}…",
returning 0 tickets. Result: every minor/major release since 2.29.0
logged "No tickets to update statuses" and skipped state transitions,
version creation, and Fix-versions assignment.
Pass plain text from the call sites so parameter() encodes exactly once.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The pull_request_review event check was failing on nearly every review,
adding noise without value. Other triggers (issue comments, PR review
comments, issues) still respond to @claude mentions.
Spawned TeamCity agents don't have github.com in known_hosts, causing
"Pull git tags" to fail with "Host key verification failed". Run
ssh-keyscan before the fetch so the agent trusts the host.
After bumping intellij-platform-gradle-plugin to 2.16.0, the
verifier defaults to checking against two IDEs (latest stable +
EAP) and reports "Package 'org.acejump' is not found" twice. The
verifier's classpath only contains bundled IDE plugins; AceJump
is a third-party Marketplace plugin we integrate with optionally
in :modules:ideavim-acejump.
Add "org.acejump" to externalPrefixes so the verifier knows those
references come from outside the IDE's own bundle and shouldn't
fail compatibility verification.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Now that 2026.1 is the current release (matches the default
ideaVersion in gradle.properties), run the standard test suite
against it alongside Latest EAP and 2025.3.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The plugin's KeepEnglishInNormalAndRestoreInInsertExtension.init()
calls exExceptionMessage("option not found") with a bundle key that
doesn't exist in IdeaVimEngineBundle.properties, so plugin-verifier
flags it as a missing-property compatibility problem against
latest-IU. This is a bug in the external plugin, not IdeaVim.
Comment out the verifier invocation until upstream
(github.com/hadix-lin/ideavim_extension) is fixed.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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>
The 262 EAP refactored ide-starter (commit aa3d516047 in
intellij-community, "AT-2967 Compile time dependency on dedicated
IDE info"): IdeProductProvider was removed, and per-IDE info now
lives in dedicated modules accessed via IdeInfo.Companion.IdeaUltimate.
Constructing IdeInfo directly is the only form that compiles on
both 261 (default ideaVersion=2026.1) and 262 (LATEST-EAP-SNAPSHOT),
since the IdeInfo data-class signature is unchanged across the
refactor. Values mirror DefaultIdeaUltimate from the new
intellij.tools.ide.starter.product.idea.ultimate module.
This unblocks :tests:split-mode-tests:compileTestKotlin on the
Latest EAP TeamCity build, which was failing with "Unresolved
reference 'IdeProductProvider'".
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The latest IntelliJ EAP ships module-descriptors.xml with new
namespace and visibility attributes (e.g. namespace="jetbrains",
namespace="$legacy_jps_library") that 2.11.0's strict xmlutil
deserializer rejects with UnknownXmlFieldException, blocking
:intellijPlatformTestClasspath resolution and preventing :test
from being scheduled at all on the Latest EAP TeamCity build.
2.12 accepted namespace/visibility, 2.15 introduced a tolerant
parser for the 262.* IDE format, 2.16 added $legacy_jps_module
namespace handling. The positional 3-arg create(type, version,
Boolean) overload was dropped in 2.15, so property-tests is
switched to the lambda form already used by every other module.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Move from the JetBrains Space-hosted custom verifier jar to a release
asset on the AlexPl292/intellij-plugin-verifier fork, and document the
refresh workflow (pull upstream, re-apply the dev-channel patch, run
publish-verifier-cli.yml, bump the URL).
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).
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>
