The tbr page was still a byte-for-byte copy of the 2.45.0 release notes,
so its content is replaced with the features and fixes currently under
To Be Released: the YankRing extension, modeless selection, the
current-search-match highlight, :stopinsert, command-line sethandler and
the macOS key repeat setting, plus the polish & fixes list.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
normal lost the newline and everything after it when the argument came from an :execute string (:exe "normal! iX\<CR>Y" typed only X), because \<CR> was parsed into a line feed instead of a carriage return and a line feed ends the ex command line; fixed by making \<CR> produce 0x0D, recognising <NL> as the <C-J> key, and having :execute hand line feeds to the parser as carriage returns for commands like :normal that take the rest of the line.
With VimEverywhere enabled, TableEverywhere left its navigation shortcuts registered on a table while focus moved into that table's own cell editor, so shifted keys such as `G` and `$` were consumed as selectLastRow/selectLastColumn instead of being typed (e.g. the Name field of the Environment Variables dialog) - the dispatcher now stands down whenever a cell editor is active, and leaving a table always unregisters the shortcuts and restores `autoStartsEdit`
When the selection is no longer ours but still holds our text minus the tail something reformatted away, the type now comes from what we published instead of being guessed from the text.
On Linux with clipboard=unnamed the `*` register is backed by the system PRIMARY selection, which stores text only, so its type was re-guessed from the text on every read. The selection can come back with trailing whitespace stripped, so a line-wise "foo \n" reads back as "foo" and gets downgraded to character-wise. We now reuse the text and type we published while we still own the selection, and only read and guess once another app claims it.
'mouse' should stop Vim from interpreting the mouse rather than disable the mouse, so we now consume only the plain left-button press over text. the platform's single hook for suppressing caret placement - and build Vim's modeless selection ourselves, leaving the context menu, gutter clicks and modifier gestures
to the IDE
MotionGroup.getMotionRange2 is a copy of VimMotionGroupBase.getMotionRange
that OperatorAction uses for g@, so every operatorfunc based operator - the
Commentary and Surround extensions, and any <Plug> operator - missed the two
range fixes of this branch. `gc}` commented one line more than `d}` deleted,
and `g@w` on the last character of the file did nothing.
Port the ':help exclusive' end adjustment and the end of file clamp, and
cover both with tests that exercise g@.
Also fixes the count for the inner quote text objects: Vim guards the
adjustment with "count < 2" in current_quote(), so any count of 2 or more
includes the quotes, not just exactly 2 (VIM-4163).
:help v_iquote - "Special case: With a count of 2 the quotes are included,
but no extra white space as with a"/a'/a`".
The count was passed to the text object handlers and then dropped, so `2i"`
behaved exactly like `i"` and left the quotes behind.
:help :s_flags - "n: Report the number of matches, do not actually
substitute". The flag was accepted and then ignored, so `:%s/a/b/n`
performed the substitution instead of counting.
The matches are counted the same way that they would be substituted, so
without the 'g' flag only the first match of each line counts, and the 'c'
flag is ignored.
The undocumented vi feature that the code already describes - ":s\/sub/"
and ":s\?sub?" reuse the last search pattern, ":s\&sub&" reuses the last
substitute pattern - never worked. The branch that parses the backslash
delimiter left the pattern as the empty string instead of clearing it, so
the block that reuses the last pattern was skipped and the empty string was
compiled as a regex, failing with E383.
The two error messages of that block were also the wrong way round: a
missing search pattern is E35 and a missing substitute pattern is E33, as
they already are in Address.
A look behind matches when its pattern ends exactly where the look behind
started. The simulation of the assertion returned as soon as it reached the
accept state, and the caller then compared that one result against the
current index, so the alternatives that were still on the stack were thrown
away.
With `\%(a\|ab\)\@<=c` on "abc" the shorter alternative was found first,
ended at the wrong index, and the whole start position was rejected, so the
positive assertion did not match and the negative one wrongly did.
The simulation now takes an optional target index. Reaching the accept state
at another index no longer stops it, so every way the pattern can match is
tried. Only the look behind passes a target index, so nothing else changes.
The backtracking simulation applied the captures of every state it visited
directly to the shared capture group collection and never undid them, so
what a failed branch captured leaked into the branch that did match.
For \zs, that moved the start of the match: `a\zsc\|ab` matched "b" instead
of "ab", because the first branch set the start of the match before failing.
Fix(VIM-4297): the same leak through \ze force ended the match. `a\zec\|ab`
matched "a" instead of "ab", because the force ended flag of the failed
branch made the end capture of the matching branch be ignored.
The capture group collection can now take and restore a snapshot of itself,
and counts its own changes. Each frame of the simulation stack remembers
that count, and every capture pushes a snapshot, so popping a frame can undo
everything that the branches explored since have captured. The stack is
shared with the nested simulations of assertions, and an assertion that does
not contribute to the match undoes its captures too.
Vim applies 'ignorecase' and \c to the individual characters and to the
ranges of a collection, but never to a character class, so \c[[:upper:]]
does not match a lowercase character.
The matcher tested the class against both the lowercase and the uppercase
variant of the character, which made \c[[:upper:]] match every letter.
: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.
