Document the VIM-330 spelling dictionary commands in the changelog and
bring whatsnew-tbr.html up to date with the changelog entries that were
not yet represented on the page.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
When in normal mode it was wierd that enter has moved between lines instead of exeecuting it. To execute command in python console cursor must be at the end of line so we move it in normal mode
SelectLastFileCommand passed 999 to selectFile(), but both implementations
only treat 99 as the "select last file" sentinel. As a result `:last` returned
an error and never switched buffers for any realistic number of open files —
a regression introduced when the original Java handler (which correctly passed
99) was rewritten in Kotlin.
Use the shared VimFile.LAST_FILE_SENTINEL constant so the command and the
implementations agree by construction, and add a behavior test that opens
several files and asserts `:last` selects the last one. The test fails against
the old 999 value and passes with the fix.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The `selectFile(count)` API uses the magic number 99 as a sentinel meaning
"select the last open file". This value was duplicated as a bare literal in
both implementations (IjFileGroup and FileRemoteApiImpl), with nothing tying
it to the callers that must produce it. Name it once on the VimFile companion
and reference it from both implementations so the value can no longer drift.
No behavior change.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
There was no count-prefixed `yy` test in the normal-mode suite, leaving the
`count - 1` / `min(..., fileSize)` line-range logic in YankGroupBase.yankLine
uncovered. Add two tests:
- `2yy` yanks the expected multiple lines.
- `5yy` near end-of-file clamps to the last line instead of running past the
end of the buffer.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
`end` is computed as `min(moveCaretToRelativeLineEnd(...) + 1, fileSize)`.
`moveCaretToRelativeLineEnd` (the only implementation, in VimMotionGroupBase)
always returns a normalized, non-negative offset, so after the `+ 1` and
`min(..., fileSize)` the result is always >= 0. The `if (end == -1) continue`
check can therefore never fire and is dead code.
The equivalent line-range computation in VimChangeGroupBase.deleteLine
correctly has no such guard, confirming this was a stale leftover. This is a
behavior-preserving cleanup. Also drops an accidental double blank line in
yankMotion.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
cells had guarded blocks which prevents from modifing document at such place and they are treated as collapsed regions.
So after adding expanding collapsed regions it was included in motion range and as it is guarded block we couldn't delete in such way
Update the changelog and the What's New page for the next release.
Changelog (CHANGES.md), added to [To Be Released]:
- Feature: VIM-1850 'keymap' option, 'iminsert', <C-^>, :loadkeymap and the
:lmap/:lnoremap/:lunmap/:lmapclear language-mapping commands
- Fix: VIM-4281 output panel and command line now refresh colors on theme change
- Merged PRs: 1929, 1928, 1925
What's New (whatsnew-tbr.html), incremental update of the existing page:
- New section for the 'keymap' language-mappings feature
- Mini cards for gx and :w with a file argument
- Fixes list entries for theme refresh, :s///g on tab-indented lines, method
navigation crash, and caret after delete-to-end from <C-O>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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.
1grzyb1