:help aquote - any trailing white space is included, unless there is none,
then leading white space is included. Vim's in_quote uses vim_iswhite, which
matches a space or a tab, but IdeaVim only looked for a space.
With a tab after the closing quote, `da"` found no trailing white space and
fell back to including the leading space, deleting the wrong text.
Char.isWhitespace() is deliberately not used, because it also matches a new
line, which would let the scan leave the line.
For a file that ends with a new line, the IDE shows an extra empty last
line. Vim has no such line - the new line is just the last line's EOL.
findSentenceStart() treated that line as a paragraph boundary and returned
its offset, which is the size of the file, so `)` on the last sentence put
the caret on a position that does not exist in Vim, and `d)` deleted the
trailing new line along with the sentence.
Clamp the paragraph offset to the last character of the file. The clamp is
applied in findSentenceStart() rather than in findNextParagraph(), because
findSentenceEnd() relies on comparing its result against the file size when
the last sentence has no terminating punctuation.
'iskeyword' only applies to Latin-1 characters. Vim classifies everything
above with a fixed table of character classes and treats a character as a
word character when its class is greater than punctuation (vim_iswordc_buf
and utf_class_buf in mbyte.c).
IdeaVim treated every character above U+00FF as a keyword character, so word
motions never stopped at non-ASCII punctuation: `w` on "foo—bar" skipped the
whole run, and `2e` on "です。next" jumped past the ideographic full stop.
Port Vim's table of blank and punctuation intervals. 'isfname' keeps
treating every multibyte character as a filename character, which is what
vim_isfilec does.
Vim's forward word motions fail at the end of the file, but `nv_wordcmd`
only reports the failure when no operator is pending. With an operator, the
operator is applied from the caret to the end of the file, so `dw` on the
last character of the file deletes that character.
IdeaVim returned Motion.Error in both cases, and getMotionRange() aborted
the operator, so `dw`, `dW` and `de` on the last character of the file did
nothing at all.
Forward word motions now opt in to clamping the failed motion to the end of
the file, which getMotionRange() (only ever called with a pending operator)
applies. Plain `w` in normal mode still beeps, and the backward motions `b`,
`ge` and `gE` are unchanged - Vim beeps for those even with an operator.
:help exclusive - when an exclusive motion ends in column 1, its end moves
to the end of the previous line and the motion becomes inclusive. Only the
second half of the rule (the motion becomes linewise when the start is at or
before the first non-blank) was implemented, in the delete and yank
operators.
Without the first half, d} from the middle of a paragraph deleted the new
line of the last line of the paragraph too, merging away the blank line that
separates the paragraphs, and y} yanked a trailing new line that Vim does
not yank.
The operators recognise the linewise half of the rule by the end of the
range being in column 1, so the end is only adjusted when the start is not
in the indent, which is exactly when Vim makes the motion inclusive instead
of linewise.
Backward motions are left alone. Vim opts the affected ones out explicitly,
e.g. <BS> and h wrapping to the previous line set CA_NO_ADJ_OP_END.
anyNonWhitespace() coerced the end of its backward scan to 0, so at offset 0
the range 0..0 inspected the character *under* the caret instead of being
empty. The caller then believed there was non-blank text before the range
start and skipped Vim's charwise-to-linewise promotion for exclusive
motions, but only at the very first character of the file.
Dropping the coercion leaves an empty 0..-1 range, matching what already
happens at every other line-start offset.
A WORD is a sequence of non-blank characters, separated with white space
(:help WORD). Vim's cls() returns the same class for every non-blank
character when cls_bigword is set, so a change of Unicode script must not
end a WORD.
charType() consulted the Hiragana/Katakana/CJK Unicode blocks before the
punctuationAsLetters (bigWord) flag, so W, E, B and dW stopped at the
boundary between scripts: E on "abcあいう def" landed on 'c' instead of 'う'.
Short-circuit on punctuationAsLetters before the script checks. The script
classes still apply to small-word motions, which is where they belong.
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>
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>
Alex Plate