Fix potential ConcurrentModificationException in statistics collection by using thread-safe collections.
Issues found:
- VimscriptState.Util and PluginState.Util used non-thread-safe HashSets
- Collections were modified from EDT/user actions but read from getMetrics()
- IntelliJ's ApplicationUsagesCollector.getMetrics() may be called on background threads
- Race conditions could cause ConcurrentModificationException or data corruption
Changes:
- Replace HashSet with ConcurrentHashMap.newKeySet() for thread-safe add/read operations
- Add @Volatile annotations to boolean flags to ensure visibility across threads
- This ensures safe concurrent access between statistics writers and collectors
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
This breaks a specific construct: `echo(42)(999)`. The `echo` command can parse multiple expressions without separating whitespace. IdeaVim now treats this example as a function call of the resul of the `(42)` expression, which is, of course, invalid. Vim evaluates expressions as it is parsing and declines to apply the `(999)` subscript because it knows the first expression is not a funcref/partial.
IdeaVim does not have this context, so cannot know that this is two expressions and not a function call.
I think it is better to support the `expr10(expr1, ...)` syntax and break this (what feels like niche) functionality than not have function calls through expression results at all.
The only change to the rules themselves is to add unary plus/minus to IntExpression and FloatExpression. This matches Vim's precedence, where the unary operator applies to numeric constants at a higher precedence than to other expressions. E.g. `-4->abs()` invokes `abs` on `-4`, while `-a->abs()` is the negative value of `abs(a)`.
The companion function `modeToMappingMode` was not used anywhere in the codebase.
The extension function `toMappingMode()` serves the same purpose and is used throughout.
Also removed unused import and extra blank line for cleaner code formatting.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
VimEditorGroupBase has been unused since its creation in April 2022. Unlike other
*Base classes in the api package (VimApplicationBase, VimMessagesBase, etc.),
VimEditorGroupBase is never extended. The actual EditorGroup implementation
directly implements the VimEditorGroup interface instead of extending this base class.
This removal cleans up dead code and reduces maintenance overhead.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Updated `integrationsTest` script to accept project directory as an argument.
- Modified `build.gradle.kts` to pass project root directory to the `integrationsTest` task.
- Improved flexibility and reusability by allowing dynamic project directory input.
- Removed all YouTrack-related helper functions from `build.gradle.kts`.
- Simplified the build script by eliminating unused code and redundant tasks.
- Improved maintainability by reducing script complexity.
- Moved `integrationsTest` logic from `build.gradle.kts` to `scripts/integrationsTest.kt`.
- Registered `integrationsTest` as a `JavaExec` task in `scripts/build.gradle.kts`.
- Improved modularity by isolating test logic into a dedicated script.
- Simplified task structure and maintained existing functionality.
- Extracted `releaseActions` logic from `build.gradle.kts` into `scripts/releaseActions.kt`.
- Registered `releaseActions` as a `JavaExec` task in `scripts/build.gradle.kts`.
- Added helper functions for YouTrack version management (`addReleaseToYoutrack`, `getVersionIdByName`, `setYoutrackFixVersion`, etc.).
- Simplified coroutine usage and modularized task logic for maintainability.
- Extracted `updateChangelog` functionality from `build.gradle.kts` into `scripts/updateChangelog.kt`.
- Registered `updateChangelog` as a `JavaExec` task in `scripts/build.gradle.kts`.
- Improved modularity and reusability by isolating changelog update logic.
- Consolidated shared changelog utilities in `scripts/changelogUtils.kt`.
- Extracted `updateMergedPr` logic from `build.gradle.kts` into `scripts/updateMergedPr.kt`.
- Registered `updateMergedPr` as a `JavaExec` task in `scripts/build.gradle.kts`.
- Improved modularity and reusability by moving update logic to a dedicated script.
- Updated task to accept arguments for `prId` and project directory.
- Extracted `updateAuthors` logic from `build.gradle.kts` into `scripts/updateAuthors.kt`.
- Registered `updateAuthors` as a `JavaExec` task in `scripts/build.gradle.kts`.
- Updated dependencies to include required libraries (`github-api` and `markdown`).
- Improved modularity and reusability of the `updateAuthors` implementation.
- Moved `slackNotification` logic from `build.gradle.kts` to `scripts/slackNotification.kt`.
- Refactored notification handling for better modularity and reusability.
- Added task registration in `scripts/build.gradle.kts` to execute the standalone script.
- Updated dependencies to include `mark-down-to-slack` for Slack message formatting.
- Replaced `updateYoutrackOnCommit` function in build script with a dedicated Kotlin `main()` entry point.
- Simplified task registration with `JavaExec` in `scripts/build.gradle.kts`.
- Integrated argument support for specifying project directory.
- Removed duplicate and redundant code for Change processing.
- Adjusted GitHub workflow to use the new task structure.
The skill was too passive and didn't guide me to find documentation issues
proactively. Updated based on the MappingScope documentation sync experience.
Key improvements:
- Add "Phase 0: Pre-Analysis Search" to find red flags before deep reading
- Establish "ground truth" from working implementations first
- Change mindset from "be conservative" to "be aggressive finding issues"
- Add explicit checklist for verifying each code example
- Emphasize checking what was REMOVED (deletions matter more than additions)
- Add step-by-step workflow with git history checks
- Include "Key Lessons Learned" section with critical insights
The skill now prioritizes finding working code as ground truth and assumes
documentation is outdated after code changes, rather than assuming it's
correct until proven otherwise.
The documentation was showing incorrect function signatures with non-existent
parameters (keys, label, isRepeatable) and not following the 2-step <Plug>
mapping pattern established in d288a52ef.
Changes:
- Remove non-existent parameters from all mapping examples
- Update all examples to use the correct 2-step pattern:
1. nnoremap("<Plug>...") for non-recursive <Plug> → action mappings
2. nmap("key", "<Plug>...") for recursive key → <Plug> mappings
- Add explanation of the 2-step pattern and its benefits in the tutorial
- Remove non-existent shortPath parameter from @VimPlugin annotation
This ensures documentation matches the actual MappingScope API and teaches
users the best practice pattern for creating mappings that can be overridden
in .ideavimrc.
