Drop the uninstall survey browser popup and the "Take Survey" entry in the
status bar widget menu.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Vim computes 'hlsearch' per screen cell during redraw and keeps no highlight objects at all, while IdeaVim materialises a RangeHighlighter per match, so highlighting the whole buffer put tens of thousands of them in the markup model for the 35 lines the user can see.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Once the highlighters cover only the viewport they are no longer a complete model of the matches, so the two callers that read the match list back out of them need another source.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Nothing kept the vimLastHighlighters list and the markup model in step, and nothing could answer which part of the document is currently highlighted - both of which scoping the highlights to the viewport needs.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Allow to disbale char-ise block comments.
Original plugin doesn't support comment part of line.
Here we add `commentary_block_comments` variable to allow to disable it
`y<C-V>{motion}` (`:help o_CTRL-V`) makes `getMotionRange` return a
rectangular block, i.e. a multi-range `TextRange` with one range per row
of the block. `YankGroupBase.yankMotion` assumed a single range and
tripped `assert(motionRange.size() == 1)`; with assertions disabled it
silently yanked only the first row of the block, characterwise.
Handle a blockwise-forced motion the way the delete path already does:
store the whole multi-range as a blockwise yank and skip the
characterwise-to-linewise promotion, which does not apply to a block.
Found by the YankDeletePropertyTest property test.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`c_CTRL-R_CTRL-F` uses the *exclusive* end offset of the current incsearch
match as the document offset to look for a filename at. When the match ends
at the very end of the document, that offset equals the text length, and
`findFilenameAtOrFollowingCursor` indexed the text with it directly.
Guard against an offset that isn't a valid index into the text, and return
null, which reports E446 "No file name under cursor". This is the same guard
that `findWordAtOrFollowingCursor` already has, and it matches Vim, which
finds no identifier or filename when the position is past the end of the line.
Found by the property based tests.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Expand % signs also during command execution, not only with tab
completion.
% is the buffer name, relative while the file is under a content root;
only :p forces the full path. Expansion runs in a single forward pass
that honours \% and never rescans the expanded name, so a file name
containing % no longer loops forever. :! expands only the file-name
specials and leaves $VAR and ~ to the shell, as Vim does.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
