Document VIM-4287 and VIM-4301 under 2.45.0 (both commits are contained
in the 2.45.0 tag) and list PRs #1946 and #1949 under Merged PRs.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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
1grzyb1