Rider's dotCover indicator is marked as "last" rather than relative to other dotnet icons. This position pushes out IdeaVim widgets, so make sure we're after "dotCoverIndicator"
See also DCVR-13021
I used the code in VimChangeGroupBase.getDeleteRangeAndType to do the check.
For an example of what this fixes, with the document:
```
${c}Hello!
```
executing "y}llp" before this change yields
```
HelHello!
lo!
```
but doing it with this change yields
```
Hello!
Hello!
````
There are several problems with it:
- It was highly unstable, so it was constantly disabled
- Qodana baseline file is huge, it's almost the size of the whole repo
Historically, IdeaVim was starting read or write action based on command type. However, this is incorrect because of several reasons:
- The command of different type may perform a write/read action
- The write lock with a lot of code inside does cause application freezes
- Since a large branching of code happens inside the write action, there is a chance of read action request, resulting in the deadlock
Also, now this prevents from implementing a proper execution of VIM-3376.
It's not clear why the write action was needed. Probably, it was a mistake and it supposed to be a check for EDT. However, since the check for EDT exists right in the constructor of the potemkin progress, let's remove it at all.
The `ge` motion incorrectly had `stopAtEmptyLine` set to false, but `ge` always stops at empty lines. This option is only applicable for forward motion, so is ignored by the implementation of `findPreviousWordEndOne`.
Adds extra tests to confirm that deleting previous word in Insert mode was already working as expected (relates to VIM-1650)
Also fixes an edge case for a test that was marked as behaving differently to Vim, but was actually showing buggy behaviour due to its unorthodox caret placement. It looked like the caret was placed at the end of the line, but it was actually placed _passed_ the last character in the file. Adding extra text below the caret placement would cause the action to behave as expected, and the test would then match Vim behaviour. However, it is possible to get this caret position in the editor and in Vim, with `virtualedit=onemore`, and the IdeaVim implementation was wrong. The test has been updated to provide the correct scenario, and the implementation has been fixed.
This is needed for the new terminal. Before this change, it was impossible to put the caret at the line end, even taking the fact the IdeaVim is disabled in the new terminal.
Simplify and reorganize logic in isEnabled() for improved readability and maintainability. Adjust logging messages for consistency and replace unused exception variable with underscore.
As the GitHub Copilot is placed right in the editor component, the IdeaVim's actions are also collected. Action promoter promotes the IdeaVim's action and, since the data context has the editor, executes a Vim's actions like backspace.
Now we make sure that IdeaVim works only in the actual editor.
Since this change may affect some places where the IdeaVim used to work, but won't work now (this will be a surprise), a registry key is introduced to help the users that face this problem.
The `editorInFocus` used the weak reference in order to avoid editor leaks. However, if the user is unlucky, the GC may be called in between the console closing and switching focus to the new editor. In this case, the logic breaks and the Editor remains in the insert mode.
Now, we store only the required information about the last used editor.
This commit fixes 2 bugs at once:
1. Correctly trim surround with closing brackets motion, e.g.: `cs()`.
It should trim all surrounding white space or leave things unchanged if
there's no space.
For example cases like these:
"( ${c}foo )" // single spaces
"( ${c}foo )" // multiple spaces
"( ${c}foo)" // assymetric spaces
"(${c} )" // single space without text
"(${c} )" // multiple spaces without text
Should trim white spaces into these results accordingly:
"${c}(foo)"
"${c}(foo)"
"${c}(foo)"
"${c}()"
"${c}()"
In case of no spaces - they should be left unchanged, e.g.:
"(${c}foo)" // no spaces around the word
"(${c})" // empty parenthesis
2. Leave empty parenthesis unchanged. IdeaVim now deleted them instead.
**Context**:
In vim surround extendsion closing brackets (`}, ], )`) should remove
whitespace when using `cs` movement.
Example:
- Before: `{ example }`
- Movement: `cs{}`
- After: `{example}`
This was because were replaced with a string from `SURROUND_PAIRS` map,
which does not have any context about removing characters.
**Solution**:
Inspired from VSCode's VIM plugin[^1], I have introduced new class
`SurroundPair` that will carry this context about need to trim
characters.
**Disclaimer**:
I have never written in `Kotlin` so solution may be not use best
practices, though at least this PR seems to fix the problem and tests
are passing.
**Ticket**:
- https://youtrack.jetbrains.com/issue/VIM-1824/Vim-Surround-Does-not-remove-whitespace-with-the-closing-bracket
[^1]: 04fe42aa81/src/actions/plugins/surround.ts (L455)
We need this for undo subsystem. Mode change is not something that we want to be a separate entity in the undo log
P.S. It's not a full list of such commands, e.g. <ESC> for leaving insert mode is missing. It is because <ESC> may insert some text after visual block mode, I'll figure out a solution for this later
1. `rawText` vs `text` is confusing and `rawText` was misused, we do not need this field in IdeaVim at all
2. `rawText` and `keys` are the same thing, just parsed. And for some reason, rawText was a nullable field
3. Register is an immutable class now
4. Working with Register class is easier and more compact now
When I added the selection clipboard, it was confusing to explain to people how this option works and why they should prepend, because the parsing was broken
I've also removed "exclude" part, because it doesn't work in IdeaVim and can confuse people
This is important for initialising options. We can't rely on FileEditorManager.selectedTextEditor, as 2024.2 changed behaviour to reset to null during creation of a new editor. This fixes tests (and option initialisation) for 242.
Also supports `mapclear!` and `unmap!`
Moves parsing of the bang modifier to the parser so we can tell the difference between `map! foo bar` and `map ! foo bar`
E.g. `map foo bar` and `vmap foo baz` would only output one map for `foo` when calling `:map`. Now it will output all maps that match the ex command's modes. This change also improves the marker characters in the first column of map output.
This was needed when action keys were registered in a comma separated list in a single XML attribute string. Additional encoding was needed for angle brackets and commas. Registration has changed, and this is no longer needed
The window splitting was refactored to initialize the editor async. So, we have to wait till the editor will become available.
This can't be done while holding the EDT, so we start this bunch of tests from the non-EDT thread.
The problem happens in tests: after the refactorings in 242, the `EditorListenerTracker` may be called before the initialization of the IdeaVim. In this case, it'll report the VimDocumentListener as a leaked listener, however, it's incorrect.
Generally, I think that this situation with the listener tracker is a bug.
There should be no changes in IdeaVim behaviour as the multicaster does the same thing: subscribes every editor on this listener. However, the multicaster does this in the "registerEditor" stage. However, I don't think this is a problem.
The problem happens in tests: after the refactorings in 242, the `EditorListenerTracker` may be called before the initialization of the IdeaVim. In this case, it'll report the FocusChangeListener as a leaked listener, however, it's incorrect.
Generally, I think that this situation with the listener tracker is a bug.
There should be no changes in IdeaVim behaviour as the multicaster does the same thing: subscribes every editor on this listener. However, the multicaster does this in the "registerEditor" stage. However, I don't think this is a problem.
With the AI functionality, the shortcut ctrl-right got more important. However, previously it was defined as VIM_ONLY shortcut. However, taking the fact that IJ defines several actions for such shortcuts, it's not clear why we prohibit the users from using these shortcuts with the IDE actions.
Taking the fact, that we default shortcuts to VIM, I expect no changes in the behaviour.
However, just arrows are still hidden from setting the IDE handler. I think, it reduces the cognitive load for the user, especially taking the fact that arrows work almost equally in vim and IJ.
List is based on Vim's documentation, although not all digraphs are documented. Additional digraphs are added based on the output of `:digraphs`. These additional digraphs include some digraphs that produce the same character, so the code is updated to handle duplicates, with the same ordering/priority as Vim.
Extra digraphs include the Euro symbol (`=e` and `Eu`), quadruple prime (`4'`) and bullet (`oo`), amongst others.
Also removes a number of non-standard digraphs. The symbols generated don't match the descriptions. The code appears to be private use, so are not reliable. Once custom digraphs are implemented, they can be easily added back in `~/.ideavimrc`
Vim only use the `~` prefix if the encoding is "latin1". We can just treat it as though the encoding is Unicode, and match the other places we format printable characters. Note that for Vim, if `'display'` contains "uhex", then all unprintable characters are shown in hex, including control characters (`^C`, etc.). IdeaVim does not support the `'display'` option.
`OperatorArguments.mode` is the mode *before* the command was completed, rather than the current mode, which is non-obvious. E.g. for a command in Insert mode, it will still be Insert, and for a (simple) command in Normal, it will still be Normal. The only difference is that a command such as `dw` would be in Operator-pending before the command is completed. That logic is not required for this method, so it's safe to use the current mode.
This allows us to start to deprecate `OperatorArguments.mode`.
`OperatorArguments.mode` is the mode *before* the command is completed, so might be Visual, Operator-pending, Insert, etc. It's not immediately obvious this is the case, so we're going to deprecate `OperatorArguments.mode` to avoid confusion with `editor.mode`.
It's not required for this method because it's only called for Visual-block mode.
Register specific handlers for Operator-pending mode instead of relying on a runtime flag for behaviour. Also refactors and renames some arrow motion handlers.
It's easier to just look at mode. We don't need the additional check on command builder, because we can't be in OP_PENDING without pushing an operator action to the command builder
Only Command has a count. The motion argument is now a sealed class hierarchy, and consists only of the motion action and optional argument. This is to reduce confusion over which count to use, and potential incorrect calculation of the count
Unlike other IDEs, Rider has multiple client sessions. The IDE itself is the "local" session, while the external ReSharper process is treated as a "frontend" process. The code to get local editors was erroneously getting `ALL` sessions, rather than just `LOCAL` sessions, and assuming that the first was the local session. In Rider, opening three instances would add three additional clients, and that would change the order.
I don't know why I changed `LOCAL` to `ALL` when previously changing this bit of code. AIUI, using `LOCAL` should work fine. If it turns out that CWM or remote dev require `ALL`, please document why.
Fixes VIM-3549
Steps to reproduce:
1. Select some text inside diff editor
2. Open 'Find in Files' window and search for file
3. Open the found file
Result: current mode is VISUAL
Some of the text input fields where Vim should not work at all had block carets.
It did not happen before, because previously we had a unique VimStateMachine for each editor and for newly created editors it was in INSERT mode. And we did call the updateSecondaryCaretsVisualAttributes method for editors that have nothing to do with Vim, but because of the INSERT mode it was looking OK.
However, now the VimStateMachine is global, and we can't rely on local INSERT anymore.
This commit forbids updating caret visual attributes for editors that do not support Vim.
NOTE: `isIdeaVimDisabledHere` is broken during editor creation handling, it always returns true. However, we do not trigger carets redraws on editor creation and do it on focus events, so it should work.
We no longer need to track a previous fallback argument type, since we don't support nested commands inside a command builder. We can just return the current argument type, or its fallback
This was to handle nested commands, e.g. inserting a digraph inside a search `d/foo<C-K>OK<CR>`. The command line now has its own command builder, so this check is no longer needed
The last command part is not guaranteed to be a "select register" part. The user might have selected a register then typed an operator, and we might be waiting for a motion.
Originally this is needed to update the dependency on AceJump, which uses the kotlin 2.0 compiler, and its classes are not compatible with the old compiler
I'm not sure what causes the issue, but everything was working when we were updating visual attributes per each caret and... let update them per each caret
Typing is more suitable for command lines than a modal input, and most likely it should be used instead
It is still possible to support typing by properly implementing the handleKey method
We do not need the `doAll` condition (because the next code block with `doAll` adjusts line and column for the next match to be correct),
And the line2 can't be >= editor.lineCount()
shouldRecord value was only updated in ModeInputConsumer when the key was not handled. But when the key is not handled, it is not passed to finishedCommandPreparation and the shouldRecord value is not used
We may create a command line via the VimCommandLineService and forget (or do not know) about calling startExEntry necessary. So we move its logic inside the creation of the command line
Initially, injector was initialized in VimPlugin, assuming that almost every interaction with the plugin goes through it. However, with the plugin evolution, this class starts to be less used.
As IJ doesn't have any single entry point for the plugins, we initialize it in multiple places.
However, the architecture where the plugin might be not initizlied is considered as a bad acrhitecture and should be reviewed.
Related ticket: VIM-3369
With gradle plugin 2.0 this cache fails on GitHub Actions. This solution is temporlly and generally the `integrationsTest` should be migrated from `doLast` to some other task approach
Why is the old interface bad?
- it is not obvious. You cannot create a new panel or check if it is already created. Only "getOrCreate" it
- output panel is bound to editor while in Vim it is global
- we have the `isActive` field and the `clear()` method at the same time, because interface implies that you store the same instance of the panel and reactivate it for each output and I don't like it. We also can forget to call `clear()` after reusing panel
- we cannot "build" output before showing to make the panel more efficient. With multiple carets we can only cal `output(oldText + newText)` for each caret, and it is bad. (imagine we have global command with a lot of matches and for each time we will need to call the `output(oldText + newText)`)
- the `output()` method shows panel, activates it and updates it
- there are more things that I do not like, but the points above should be already enough
This bug was caused by two reasons:
1. KeyHandler state is not longer per-editor and we can't reset it on editor creation
2. We do not need to do such things on editor creation. What actually matters is focusing the editor
IJ has it's own kotlin libs, as well as fleet. So, let's use kotlin reflection library only to compile the project without bundling these jars into the resulting plugin
.name will show the correct name "IdeaVim" in IJ
`misc.xml` contains information about the annotations that should be considered as "EntryPoints" for the function. With this, they'll not be marked as unused
Explicit API mode has been removed due to several reasons impacting developer productivity and the natural coding style in Kotlin.
Firstly, the mode was found to be more irritating than beneficial, as it forced unnecessary verbosity without enhancing thoughtfulness in coding. It often prompted automatic 'public' insertion reactions to red-highlighted code, which did not genuinely encourage more deliberate coding decisions.
Secondly, our aim is to form a robust API primarily through interfaces, which inherently define public scope and duty, rendering explicit API mode somewhat redundant.
Lastly, the additional verbosity caused by explicit API mode expanded code lines affecting code readability.
The compatibility with the existing plugins is verified via the compatibility checker, so no JetBrains plugins will be affected
IntelliJ has multiple soft wrap options. One for main editors, another for consoles and a third for previews. This can lead to inconsistencies if initialising a console based on a main editor when both have default values, versus the same scenario when the main editor has an explicit value. Furthermore, the run console's soft-wraps toggle button uses the global value, so can get out of sync if the local value is initialised to an explicit value. This change will only copy the soft wrap value over during initialisation for similar editors (main editor, preview, diff) and not for different editors (console).
Fixes VIM-3450
The option should be "local-noglobal", and reset to default. Copying the value could cause the file to be converted immediately, possibly with a warning dialog
Fixes VIM-3467
The trailing newline was never necessary. The text field always stripped it, but the test code didn't. The previous commit pulled this behaviour out of the UI code, so the test code behaves the same as the UI.
This commit fixes all of the tests that were broken by that change. No other logic has been changed.
The ex text field and output pane will correctly resize and reposition if visible when the IDE zoom value changes. If the editor's font size is zoomed with the mouse wheel, the panels are hidden, so they do not obscure the font zoom indicator widget
Fixes VIM-3417
Without this, running tests could take up to 1 minute, mostly spent configuring Gradle. It appears that the extractor transformer would extract the IDE on each run.
Binary releases can be used again now that the latest builds of 241 (2024.1.4) and 242 (EAP) include updates to the Plugin DevKit plugin that can download sources for binary releases. (Binary releases mean the referenced IDE is extracted and run from the same binaries as consumer releases).
This fixes verifyPlugin, which didn't support binary releases being disabled.
If IntelliJ's vertical scroll offset is set to the value of the 'scrolloff' option, IntelliJ's own implementation kicks in. This implementation includes virtual space at the bottom of the file in its calculation, scrolling to a different offset to IdeaVim's. In some circumstances, IdeaVim no longer scrolls, so the last line would no longer stick to the bottom of the screen after `G`. In other circumstances, the scroll would correctly reset, but there would be a visible flash as the editor scrolls to the wrong offset and then back, especially when using backspace at the bottom of the file.
Fixes VIM-3474
Ensures that the editor listeners are only registered once when the editor is created. IdeaVim uses two different events to track editor creation, to try to understand how the editor is being created (new window, split, preview, etc.) and this can lead to calling the `EditorListeners.add` method twice. This would create a second `Disposable` and cause handlers to leak. This is most visible when creating the first window and then disabling IdeaVim. This window would still handle drag events like IdeaVim, even changing the caret back to block after the drag finishes.
The autobuilder action can't resolve the 'by project' property to know what our source compatibility is, so we need to give it a hint. If we don't, it will assume the lowest version compatible with the current version of Gradle, which right now is 11.
This value doesn't have to match the `javaVersion` property, but has to allow us to resolve dependencies. Currently, we require at least version 17.
Previously, we executed processings first and updated the state afterward. This approach could be problematic for asynchronous key processing, as Fleet might access the current state, which, in the context of async key processing, is a snapshot before execution and does not reflect the actual current KeyHandlerState
Removes a workaround that would break moving a range to the current line because it would always move the caret to the start of the range. Now positions the caret to the start of the selection if there is one. This also means we can remove the SAVE_VISUAL flag from JoinLinesCommand
Fixes VIM-2936
Handles validation of count and correctly moves caret to end of range after execution. Also fix issue where the results of :print are accumulated and not cleared.
Fixes VIM-2570
Made it explicit to get the count from argument and/or range. Default count is not passed, because it was never used. Added some tests where possible, but hard to test select file and friends
As this is considered as a VERY bad practice, it makes sense in this particular case. Generally, we need an updated release process so such things don’t happen
When performing a substitute command with confirmation, the height of the editor content pane should be reduced by the height of the ex entry panel. IdeaVim would do this correctly when moving a search result to the bottom of the file, but not when the result was on the last line of the file. Because the wrong height was used, IdeaVim would decide that no scrolling was necessary and the result in the last line would be obscured.
Fixes VIM-1560
This is a messy quick fix, as the search group needs a lot of tidying up right now. Perhaps a better implementation would be to move the implementation of the global command into the search group - processGlobalCommand, like we already have processSearchCommand and processSubstituteCommand
Fixes VIM-3348
Also fixes a memory leak registering a disposable for each yank, allows config variables to be numbers rather than strings and removes highlights when IdeaVim is disabled
Fixes VIM-2236
There are a lot of incompatibilities with IdeaVim on 241 if it's built on 233
Also, this time the special branch for the IJ version won't be created. Previously on bumping the version of IJ, we've created the branch to keep the reference to the moment when it happened. However, IJ version bumps are easy to trace anyway by git.
We should calculate the line above based on logical position rather than visual position.
This issue was detected thanks to newly introduced soft wraps and proprty tests
1. Now we have two parallel commandBuilders: for the editor and for the command prompt. It's done for sequence of keys like `d/foo<C-R>"<CR>` where we have two different commands that are built at the same time.
2. We simplified the CommandConsumer and made the logic more straightforward. `/`, `?` and `:` enter the command mode, while pressing final `<CR>` fires the command execution.
In a future commit, I'm going to make ProcessExEntryAction responsible for processing both search and ex commands. Search commands are motions that are executed for each caret, while ex-commands are executed once. The per-caret code is held internally by the ex commands themselves.
The current solution is definitely not the right one, and the whole ex command subsystem needs to be reviewed and refactored:
1. Some commands can be motions, which is currently not supported.
2. We need to figure out a gentle way of handling multiple carets.
Options are not reset if they've been explicitly set by the user (e.g. `:set list` or _View | Active Editor | Show Whitespaces_). They are reset if they were explicitly set in `~/.ideavimrc`.
Also bumps the IDE build number to 233.11799.241 in order to use EditorSettingsExternalizable.PropNames
String and number/toggle options have different and opposite behaviour for `:set {option}<` and `:setlocal {option}<`. This change matches Vim's behaviour.
It now shows visual lines relative to the caret's visual line, rather than relative to the caret's logical line. This still isn't correct, and we should be showing the relative count of Vim logical lines (buffer lines + fold lines) but this matches movement so is more helpful
While they are core Vim options, they are implemented by the host, not by the engine. If another host wants to support these options, they can add them in their implementation layer.
IntelliJ ties the hard wrap right margin guide with the other visual guides, and it's not possible to show one without the other. In Vim, you can show the hard wrap margin by adding "+0" to 'colorcolumn', so in IdeaVim, we automatically add this.
Also supports overriding local-to-buffer options with IDE values, ensuring that changes to the option/IDE value are applied to all editors for the buffer.
Fixes VIM-1310
There is no need to clean up the requiredShortcuts after turning off the plugin. Also, previously this set was not populated properly and keys that were added by ideavimrc or by user were not restored
EditorDataContext cannot be used because the platform cannot convert it to the async data context. Taking the fact that it's not clear why this custom context exists, I decided to get rid of it at all.
```
Cannot convert to AsyncDataContext at 'keyboard shortcut' DataContextWrapper(CaretSpecificDataContext(com.maddyhome.idea.vim.helper.EditorDataContext)). Please use CustomizedDataContext or its inheritors like SimpleDataContext
```
Class EditorDataContext cannot be removed because it's used in github.zgqq.intellij-enhance plugin
EditorDataContext cannot be used because the platform cannot convert it to the async data context. Taking the fact that it's not clear why this custom context exists, I decided to get rid of it at all.
```
Cannot convert to AsyncDataContext at 'keyboard shortcut' DataContextWrapper(CaretSpecificDataContext(com.maddyhome.idea.vim.helper.EditorDataContext)). Please use CustomizedDataContext or its inheritors like SimpleDataContext
```
EditorDataContext cannot be used because the platform cannot convert it to the async data context. Taking the fact that it's not clear why this custom context exists, I decided to get rid of it at all.
```
Cannot convert to AsyncDataContext at 'keyboard shortcut' DataContextWrapper(CaretSpecificDataContext(com.maddyhome.idea.vim.helper.EditorDataContext)). Please use CustomizedDataContext or its inheritors like SimpleDataContext
```
This is a part of VIM-3376. This context will not be a custom EditorDataContext, but some context created by the platform.
In some places we don't have any kind of "current context", but we have to use it for the function. However, such context can be simply retrieved from the editor.
This one was added after the implementation of cmap in 5c9faba7f4
EditorDataContext cannot be used because the platform cannot convert it to the async data context. Taking the fact that it's not clear why this custom context exists, I decided to get rid of it at all.
```
Cannot convert to AsyncDataContext at 'keyboard shortcut' DataContextWrapper(CaretSpecificDataContext(com.maddyhome.idea.vim.helper.EditorDataContext)). Please use CustomizedDataContext or its inheritors like SimpleDataContext
```
EditorDataContext cannot be used because the platform cannot convert it to the async data context. Taking the fact that it's not clear why this custom context exists, I decided to get rid of it at all.
```
Cannot convert to AsyncDataContext at 'keyboard shortcut' DataContextWrapper(CaretSpecificDataContext(com.maddyhome.idea.vim.helper.EditorDataContext)). Please use CustomizedDataContext or its inheritors like SimpleDataContext
```
This context was added long ago, but I wasn't able to find specific reasons for that. Currently, such custom contexts cannot work with the intellij platform and should be refactored or removed. The issues with this context are that it cannot be converted to the async data context by the platform.
Taking the fact that the reason for this context was not found, I decided to get rid of it.
The issue from the platform looks like this
```
Cannot convert to AsyncDataContext at 'keyboard shortcut' DataContextWrapper(CaretSpecificDataContext(com.maddyhome.idea.vim.helper.EditorDataContext)). Please use CustomizedDataContext or its inheritors like SimpleDataContext
```
Here the EditorDataContext is mentioned instead of CaretAndEditorData context, however, I'll clean up both contexts during this refactoring
It was used in the action system for mapping to the `<Action>` keyword and in commit 256f5fcd0e it's mentioned that the EditorActionHandler was not working without this context. However, currently both cases work fine without addition wrapping.
IdeaVim is an open source project created by 80+ contributors. Would you like to make it even better? That’s wonderful!
IdeaVim is an open source project created by 130+ contributors. Would you like to make it even better? That’s wonderful!
This page is created to help you start contributing. And who knows, maybe in a few days this project will be brighter than ever!
:warning: The plugin is currently under a huge refactoring aiming to split into vim-engine and IdeaVim in order to
support the new [Fleet IDE](https://www.jetbrains.com/fleet/). Please see [Fleet refactoring](#Fleet-refactoring).
# Awards for Quality Contributions
In February 2025, we’re starting a program to award one-year All Products Pack subscriptions to the implementers of quality contributions to the IdeaVim project. The program will continue for all of 2025 and may be prolonged.
Subscriptions can be awarded for merged pull requests that meet the following requirements:
- The change should be non-trivial, though there might be exceptions — for example, where a trivial fix requires a complicated investigation.
- The change should fully implement a feature or fix the root cause of a bug. Workarounds or hacks are not accepted.
- If applicable, the change should be properly covered with unit tests.
- The work should be performed by the contributor, though the IdeaVim team is happy to review it and give feedback.
- The change should fix an issue or implement a feature filed by another user. If you want to file an issue and provide a solution to it, your request for a license should be explicitly discussed with the IdeaVim team in the ticket comments.
We'd like to make sure this award program is helpful and fair. Since we just started it and still fine-tuning the details, the final say on giving licenses remains with the IdeaVim team and the requirements might evolve over time.
Also, a few notes:
- If you have any doubts about whether your change or fix is eligible for the award, get in touch with us in the comments on YouTrack or in any other way.
- Please mention this program in the pull request text. This is not an absolute requirement, but it will help ensure we know you would like to be considered for an award, but this is not required.
- During 2025, a single person may only receive a single subscription. Even if you make multiple contributions, you will not be eligible for multiple awards.
- Any delays caused by the IdeaVim team will not affect eligibility for an award if the other requirements are met.
- Draft pull requests will not be reviewed unless explicitly requested.
- Tickets with the [ideavim-bounty](https://youtrack.jetbrains.com/issues?q=tag:%20%7BIdeaVim-bounty%7D) tag are good candidates for this award.
## Before you begin
- The project is written in Kotlin and Java. Choose whichever language you feel more comfortable with,
or maybe one that you’d like to get to know better (why not start [learning Kotlin](https://kotlinlang.org/docs/tutorials/) right now?).
- The project is primarily written in Kotlin with a few Java files. When contributing to the project, use Kotlin unless
you’re working in areas where Java is explicitly used.
- If you come across some IntelliJ Platform code, these links may prove helpful:
* [IntelliJ Platform community space](https://platform.jetbrains.com/)
- Having any difficulties?
Join the brand new
[](https://gitter.im/JetBrains/ideavim?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
for IdeaVim developers and contributors!
Ask any questions in [GitHub discussions](https://github.com/JetBrains/ideavim/discussions) or [IntelliJ Platform community space](https://platform.jetbrains.com/).
OK, ready to do some coding?
@@ -62,12 +86,16 @@ for a few days or send it to a friend for testing.
If you are looking for:
- Vim commands (`w`, `<C-O>`, `p`, etc.):
- Any particular command:`package-info.java`.
- Any particular command:
- [Commands common for Fleet and IdeaVim](vim-engine/src/main/resources/ksp-generated/engine_commands.json)
- [IdeaVim only commands](src/main/resources/ksp-generated/intellij_commands.json)
- How commands are executed in common: `EditorActionHandlerBase`.
- Key mapping: `KeyHandler.handleKey()`.
- Ex commands (`:set`, `:s`, `:nohlsearch`):
- Any particular ex command: package `com.maddyhome.idea.vim.ex.handler`.
- Any particular command:
- [Commands common for Fleet and IdeaVim](vim-engine/src/main/resources/ksp-generated/engine_ex_commands.json)
- [IdeaVim only commands](src/main/resources/ksp-generated/intellij_ex_commands.json)
- Vim script grammar: `Vimscript.g4`.
- Vim script parsing: package `com.maddyhome.idea.vim.vimscript.parser`.
- Vim script executor: `Executor`.
@@ -78,7 +106,7 @@ If you are looking for:
- Common features:
- State machine. How every particular keystroke is parsed in IdeaVim: `KeyHandler.handleKey()`.
@@ -106,7 +134,7 @@ Cras id tellus in ex imperdiet egestas.
carets, dollar motion, etc.
##### Neovim
IdeaVim has an experimental integration with neovim in tests. Tests that are performed with `doTest` also executed in
IdeaVim has an integration with neovim in tests. Tests that are performed with `doTest` also executed in
neovim instance, and the state of IdeaVim is asserted to be the same as the state of neovim.
- Only tests that use `doTest` are checked with neovim.
- Tests with `@VimBehaviorDiffers` or `@TestWithoutNeovim` annotations don't use neovim.
@@ -132,14 +160,15 @@ We also support proper command mappings (functions are mapped to `<Plug>...`), t
- Magic is supported as well. See `Magic`.
## Fleet refactoring
At the moment, IdeaVim is under an active refactoring aiming to split IdeaVim into two modules: vim-engine and IdeaVim.
## Fleet
The IdeaVim plugin is divided into two main modules: IdeaVim and vim-engine.
IdeaVim serves as a plugin for JetBrains IDEs, while vim-engine is an IntelliJ Platform-independent Vim engine.
This engine is utilized in both the Vim plugin for Fleet and IdeaVim.
If you develop a plugin that depends on IdeaVim: We have an instrument to check that our changes don't affect
the plugins in the marketplace. Also, we commit to support currently used API at least till the end of 2022.
the plugins in the marketplace.
If you still encounter any issues with the newer versions of IdeaVim, please [contact maintainers](https://github.com/JetBrains/ideavim#contact-maintainers).
We kindly ask you not to use anything from the new API (like `VimEditor`, `injector`) because at the moment we don't
guarantee the compatibility of this API in the future versions.
-----
@@ -162,6 +191,7 @@ This is just terrible. [You know what to do](https://github.com/JetBrains/ideavi
The power of contributing drives IdeaVim :muscle:. Even small contributions matter!
See [CONTRIBUTING.md](CONTRIBUTING.md) to start bringing your value to the project.
See the contribution guide in [CONTRIBUTING.md](CONTRIBUTING.md) to start bringing your value to the project.
😎 In 2025, we launched a rewards program. See the guide for details.
Authors
-------
@@ -325,11 +326,11 @@ IdeaVim tips and tricks
-`set ideajoin` to enable join via the IDE. See the [examples](https://jb.gg/f9zji9).
- Make sure `ideaput` is enabled for `clipboard` to enable native IJ insertion in Vim.
- Sync IJ bookmarks and IdeaVim global marks: `set ideamarks` (works for marks with capital letters only)
- Check out more [ex commands](https://github.com/JetBrains/ideavim/wiki/%22set%22-commands).
- Check out more [ex commands](https://github.com/JetBrains/ideavim/wiki/set-commands).
- Use your vim settings with IdeaVim. Put `source ~/.vimrc` in `~/.ideavimrc`.
- Control the status bar icon via the [`ideastatusicon` option](https://github.com/JetBrains/ideavim/wiki/%22set%22-commands).
- Not familiar with the default behaviour during a refactoring? See the [`idearefactormode` option](https://github.com/JetBrains/ideavim/wiki/%22set%22-commands).
- Control the status bar icon via the [`ideastatusicon` option](https://github.com/JetBrains/ideavim/wiki/set-commands).
- Not familiar with the default behaviour during a refactoring? See the [`idearefactormode` option](https://github.com/JetBrains/ideavim/wiki/set-commands).
Some facts about Vim
-------
@@ -369,6 +370,14 @@ is the full list of synonyms.
- Fancy constants for [undolevels](https://vimhelp.org/options.txt.html#%27undolevels%27):
> The local value is set to -123456 when the global value is to be used.
- Vi (not Vim) is a POSIX standard, and [has a spec](https://pubs.opengroup.org/onlinepubs/9699919799/utilities/vi.html)! Vim is mostly POSIX compliant when Vi compatibility is selected with the `'compatible'` option, but there are still some differences that can be changed with `'copoptions'`. The spec is interesting because it documents the behaviour of different commands in a stricter style than the user documentation, describing the current line and column after the command, for example. [More details can be found by reading `:help posix`](https://vimhelp.org/vi_diff.txt.html#posix).
- The Vim documentation contains many easter eggs. We encounter them occasionally, but GitHub user mikesmithgh has compiled a substantial collection [here](https://github.com/mikesmithgh/vimpromptu).
- In addition to `:call err_teapot()`, which returns `E418: I'm a teapot`, there is also `:call err_teapot(1)`, which returns `E503: Coffee is currently not available`. Naturally, this is also supported in IdeaVim.
- Insert mode has all `Ctrl` keys mapped, except `Ctrl-B`. In the documentation, it is marked as **"CTRL-B in Insert
mode gone"**. Call `:h i_CTRL-B-gone` in Vim to read why `Ctrl-B` was removed.
We’ve launched a program to reward quality contributions with a one-year All Products Pack subscription. Learn more at: <a href="https://github.com/JetBrains/ideavim/blob/master/CONTRIBUTING.md">CONTRIBUTING.md</a> .
At the moment, the default key binds for this plugin do not get mapped correctly in IdeaVim (see [VIM-2178](https://youtrack.jetbrains.com/issue/VIM-2178)). To enable the default key binds, add the following to your `.ideavimrc` file...
```
" Remap multiple-cursors shortcuts to match terryma/vim-multiple-cursors
nmap <C-n> <Plug>NextWholeOccurrence
xmap <C-n> <Plug>NextWholeOccurrence
nmap g<C-n> <Plug>NextOccurrence
xmap g<C-n> <Plug>NextOccurrence
xmap <C-x> <Plug>SkipOccurrence
xmap <C-p> <Plug>RemoveOccurrence
" Note that the default <A-n> and g<A-n> shortcuts don't work on Mac due to dead keys.
" <A-n> is used to enter accented text e.g. ñ
" Feel free to pick your own mappings that are not affected. I like to use <leader>
nmap <leader><C-n> <Plug>AllWholeOccurrences
xmap <leader><C-n> <Plug>AllWholeOccurrences
nmap <leader>g<C-n> <Plug>AllOccurrences
xmap <leader>g<C-n> <Plug>AllOccurrences
```
</details>
@@ -303,7 +321,10 @@ If you want to optimize highlight duration, assign a time in milliseconds:
If you want to change background color of highlight you can provide the rgba of the color you want e.g.
@@ -5,9 +5,9 @@ Using actions from external plugins is the same, as tracking and reusing any IDE
1. Install the plugin via Marketplace
2. Enable action tracking. You can enable it by one of the following ways:
* Execute `:set trackactionids` ex command or just `:set tai`
* Open the "Find actions" window by pressing `Ctrl-Shift-A` and search for "Track Action Ids" to find the toggle that enables and disables action tracking
* Open the "Find actions" window by pressing `Ctrl-Shift-A` and search for "Track Action IDs" to find the toggle that enables and disables action tracking
3. Execute the plugin action the way intended by plugin author "See Edit menu or use ⇧ + ⌥ + U / Shift + Alt + U" or just find the `Toggle Camel Case` action in the "Find actions" window (`Ctrl-Shift-A`). If you action tracking is on, you will see this notification in your right bottom corner:
- You can read a [post](https://github.com/JetBrains/ideavim/wiki/how-many-modes-does-vim-have) about how modes work in Vim and IdeaVim.
- Have you ever used `U` after `dd`? [Don't even try](https://github.com/vim/vim/blob/759d81549c1340185f0d92524c563bb37697ea88/src/ops.c#L874).
- A lot of variables that refer to visual mode start with two uppercase letters, e.g. `VIsual_active`. [Some examples](https://github.com/vim/vim/blob/master/src/normal.c#L17).
As mentioned [here](https://vi.stackexchange.com/a/42885/12441), this was done this way to avoid the clash with X11.
- Other [strange things](https://github.com/vim/vim/blob/759d81549c1340185f0d92524c563bb37697ea88/src/ex_docmd.c#L1845) from vi:
* ":3" jumps to line 3
* ":3|..." prints line 3
* ":|" prints current line
- Vim script doesn't skip white space before comma. `F(a ,b)` => E475.
- Fancy constants for [undolevels](https://vimhelp.org/options.txt.html#%27undolevels%27):
> The local value is set to -123456 when the global value is to be used.
- Vi (not Vim) is a POSIX standard, and [has a spec](https://pubs.opengroup.org/onlinepubs/9699919799/utilities/vi.html)! Vim is mostly POSIX compliant when Vi compatibility is selected with the `'compatible'` option, but there are still some differences that can be changed with `'copoptions'`. The spec is interesting because it documents the behaviour of different commands in a stricter style than the user documentation, describing the current line and column after the command, for example. [More details can be found by reading `:help posix`](https://vimhelp.org/vi_diff.txt.html#posix).
- The Vim documentation contains many easter eggs. We encounter them occasionally, but GitHub user mikesmithgh has compiled a substantial collection [here](https://github.com/mikesmithgh/vimpromptu).
- In addition to `:call err_teapot()`, which returns `E418: I'm a teapot`, there is also `:call err_teapot(1)`, which returns `E503: Coffee is currently not available`. Naturally, this is also supported in IdeaVim.
- Insert mode has all `Ctrl` keys mapped, except `Ctrl-B`. In the documentation, it is marked as **"CTRL-B in Insert
mode gone"**. Call `:h i_CTRL-B-gone` in Vim to read why `Ctrl-B` was removed.
Define the behavior of IdeaVim icon in the status bar.
Use one of the following values:
- enabled - icon is shown in the status bar
- gray - use the gray version of the icon
- disabled - hide the icon
IdeaVim provides its own implementation for handling scroll jump and offset, even though IntelliJ-based IDEs have similar functionality (there are differences in behaviour).
When IdeaVim is hosted in an IntelliJ-based IDE (but not JetBrains Fleet), the following options map to the equivalent IDE settings:
`ideawrite``ideawrite` String (default "all")
"file" or "all". Defines the behaviour of ":w" command.
Value "all" enables execution of ":wa" (save all) command on ":w" (save).
This feature exists because some IJ options like "Prettier on save" or "ESlint on save"
work only with "save all" action. If this option is set to "all", these actions work
also with ":w" command.
`lookupkeys``lookupkeys` List of strings
List of keys that should be processed by the IDE during the active lookup (autocompletion).
For example, <Tab> and <Enter> are used by the IDE to finish the lookup,
`ideavimsupport``ideavimsupport` List of strings (default "dialog")
Define the list of additional buffers where IdeaVim is enabled.
- dialog - enable IdeaVim in dialogs
- singleline - enable IdeaVim in single line editors (not suggested)
```
'scrolljump' 'sj' Minimal number of lines to scroll
'scrolloff' 'so' Minimal number of lines above and below the cursor
'sidescroll' 'ss' Minimal number of columns to scroll horizontally
'sidescrolloff' 'siso' Minimal number of columns to left and right of cursor
```
----------
[1] - cursor keys, <End>, <Home>, <PageUp> and <PageDown>
## IdeaVim options for IntelliJ-based IDE features
Some Vim features cannot be implemented by IdeaVim, and must be implemented by the host IDE, such as showing whitespace and line numbers, and enabling soft-wrap.
The following options modify equivalent settings and features implemented by IntelliJ-based IDEs.
There is some mismatch when trying to map Vim options, most of which are local options, to IDE settings, which are mostly global-local.
The Vim option will always reflect the effective value of the IDE setting for the current editor, and modifying the Vim option will update the local value of the IDE setting.
The default value of the Vim option set during startup is not passed to the IDE setting.
If the IDE setting has a way to modify the local value, such as entries in the _View | Active Editor_ menu, then changing this will update the current editor and be reflected in the Vim option value.
If the IDE setting can only modify its global setting in the main _Settings_ dialog, this change does not always update the current editor (because the local IDE setting has been modified and takes precedence).
IdeaVim tries to make this work more naturally by updating the editor and local Vim option when a global value changes unless the Vim option has been explicitly set in Command-line mode.
In other words, if the local Vim value is explicitly set for a window or buffer, interactively, then it should not be reset.
If the Vim option was explicitly set in `~/.ideavimrc` however, then the value will be reset, because this can be viewed as a "global" value - set once and applied to subsequently opened windows.
(This should not be confused with Vim's concept of global options, which are mainly used to initialise new windows.)
The local Vim option can always be reset to the global IDE setting value by resetting the Vim option to default with the `:set {option}&` syntax.
```
'bomb' 'bomb' Add or remove a byte order mark (BOM) to the
current file. Unlike Vim, the file is modified
immediately, and not when saved
'breakindent' 'bri' Indent soft wrapped lines to match the first
line's indent
'colorcolumn' 'cc' Maps to IntelliJ's visual guide columns
'cursorline' 'cul' Highlight the line containing the cursor
'fileencoding' 'fenc' Change the encoding of the current file. The file
is modified and written immediately, rather than
waiting to be saved
Note that the names of the encoding might not
match Vim's known names
'fileformat' 'ff' Change the file format - dos, unix or mac
The file is modified immediately, rather than
when saved
'list' 'list' Show whitespace. Maps to the editor's local
setting in the View | Active Editor menu
'number' 'nu' Show line numbers. Maps to the editor's local
setting in the View | Active Editor menu
'relativenumber' 'rnu' Show line numbers relative to the current line
'textwidth' 'tw' Set the column at which text is automatically
wrapped
'wrap' 'wrap' Enable soft-wraps. Maps to the editor's local
setting in the View | Active Editor menu
```
## IdeaVim only options
These options are IdeaVim only, and not supported by Vim.
They control integration with the host IDE.
Unless otherwise stated, these options do not have abbreviations.
```
'ideacopypreprocess' boolean (default off)
global or local to buffer
When enabled, the IDE will run custom copy pre-processors over text
copied to registers. These pre-processors can perform transformations
on the text, such as converting escape characters in a string literal
into the actual control characters in a Java file.
This is not usually the expected behaviour, so this option's default
value is off. The equivalent processing for paste is controlled by the
"ideaput" value to the 'clipboard' option.
'ideaglobalmode' boolean (default off)
global
This option will cause IdeaVim to share a single mode across all open
windows. In other words, entering Insert mode in one window will
enable Insert mode in all windows.
'ideajoin' boolean (default off)
global or local to buffer
When enabled, join commands will be handled by the IDE's "smart join"
feature. The IDE can change syntax when joining lines, such as merging
string literals or if statements. See the wiki for more examples. Not
all languages support smart join functionality.
'ideamarks' boolean (default on)
global
Maps Vim's global marks to IDE bookmarks.
'idearefactormode' string (default "select")
global or local to buffer
Specifies the mode to be used when a refactoring selects text to be
edited (e.g. renaming, live template fields, introduce variable, etc):
keep Keep the current mode
select Switch to Select mode
visual Switch to Visual mode
This option is only used when the refactoring is started in Normal,
Insert or Replace mode. Visual or Select modes are not changed.
'ideastatusicon' string (default "enabled")
global
This option controls the behaviour and appearance of the IdeaVim icon
in the status bar:
enabled Show the icon in the status bar
gray Show the gray version of the icon
disabled Hide the icon
'ideavimsupport' string (default "dialog")
global
A comma-separated list of additional buffers or locations where
IdeaVim should be enabled:
dialog Enable IdeaVim in editors hosted in dialogs
singleline Enable IdeaVim in single line editors (not recommended)
The IDE's editor component can be used in many places, such as VCS
commit tool window, or inside dialogs, and even as single line fields.
'ideawrite' string (default "all")
global
This option defines the behaviour of the :w command:
file Save the current file only
all The :w command works like :wa and invokes the Save All
IDE action. This allows options such as "Prettier on
save" or "ESlint on save" to work with the :w command,
// "cc.implicated.intellij.plugins.bunny", // I don't want to include this plugin in the list of IdeaVim plugins as I don't understand what this is for
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
