During mouse dragging there could be a case where during drag the editor was closed which resulted in an invalid state in ListenerSuppressor with not removed caretListenerSuppressor. More roboust approach is to track mouseDragging as state.
`val func= arguments[0]` was missing a space before `=`. This is the only
such occurrence in the entire vim-engine and IntelliJ main source, so it is
a clear unintended slip in the recently-added `call()` function rather than
a deliberate style choice. Align it with Kotlin conventions and the rest of
the codebase.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Replace inline fully-qualified references to
com.maddyhome.idea.vim.state.mode.CtrlXCompletionMode with a proper
import, matching the sibling completion actions
(InsertFilePathCompletionAction, InsertXCompletionAction) in the same
package. Behavior is unchanged; this only improves readability and
import consistency.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
To enable textobj-user we had to allow parsing function names with # inside. previousle we stripped out everything before #. so for example foo#bar#baz resulted in just baz
When command was executed against visual selection and there was additionally % passed visual selection was ignored and command was executed against whole file.
In vim % is ignored. this commit fixes this bug and match vim behaviour
"U" undoes all changes and most recently edited line. Implemented in simmilar way as nvim does by tracking snapshot of last edited line and then just restoring that snapshot.
When undo was in macro it couldn't be replayed as it was already in single command executiion. So other commands modified editor and when undo was trying execute those commands didn't yet commit and in UndoManager in Ij there is
```
if (document.getTextLength() != fromLength) throw new UnexpectedUndoException("Unexpected document state");
```
So we have to execute each command separately during macro execution
count(list, expr, ic, start) handled the start index incorrectly:
- Negative start indices (which Vim counts from the end of the list)
were ignored, falling back to counting the whole list.
- An out-of-range start index silently counted the whole list instead
of raising an error.
Vim resolves the start index via list_find(), which supports negative
indices and reports E684 (list index out of range) when the index is
invalid. Match that behavior: normalize negative indices and throw E684
for out-of-range values. The start argument is only applied when
explicitly provided, so count(list, expr) on an empty list still
returns 0 rather than erroring.
Adds regression tests for zero, negative, and out-of-range start indices.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Vim's get(list, idx [, default]) supports negative indices, which count
from the end of the list (e.g. -1 is the last item). IdeaVim used
List.getOrElse(idx) directly, which treats any negative index as
out-of-bounds and returns the default value instead.
Normalize negative indices before lookup, matching the pattern already
used in remove(). Adds regression tests for negative and out-of-range
negative indices.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The digraph consumer is before the char argument consumer, so digraph keys will be processed first. If a key isn't a digraph key, it is ignored and the char argument consumer will process it; the digraph consumer doesn't need to set a fallback argument type and repost the key.
processing escape might be entered from multiple places at once but we don't wont to repeat it.
For example, it might be called from standard esc processing and Rider Escape lookup which results in duplicated text insertion
When user had mapping for key `onUnfinishedMappingSequenceTimeout` executed this key mapping again which resulted in duplicated key in macro. To prevent that we took simillar approach as nvim to not record mapped keystrokes
1grzyb1