| Age | Commit message (Collapse) | Author | Files |
|---|
|
vim-patch:9.2.0384: stale Insstart after <Cmd> cursor move breaks undo
Problem: A <Cmd> command executed from Insert mode can sync undo and
move the cursor before the next edit. stop_arrow() saved the
new cursor line for undo, but left Insstart at the previous
insertion point. A line-start backspace could then delete
lines above the saved line without saving the joined range,
leaving a pending undo entry whose bottom resolved above
its top and raising E340.
Solution: Update Insstart and Insstart_textlen after the pending undo
save so the next edit starts from the command-updated cursor
position (Jaehwang Jung).
closes: vim/vim#20031
AI-assisted: Codex
https://github.com/vim/vim/commit/d4fb31762ea0b9de6fffb529c4ffee509621f74c
Co-authored-by: Jaehwang Jung <tomtomjhj@gmail.com>
|
|
- `src/nvim/ex_cmds_defs.h`: use "U" instead of "u" per
`readability-uppercase-literal-suffix`
|
|
(#38749)
Problem: 'linebreak' may lead to wrong Visual block highlighting when
end char occupies multiple cells (after 7.4.467).
Solution: Exclude 'linebreak' from the ending column instead of setting
'virtualedit' temporarily (zeertzjq).
fixes: vim/vim#19898
closes: vim/vim#19900
https://github.com/vim/vim/commit/23be1889d1a1212445ca8bb9cd378484d3755f79
|
|
Problem:
Currently, we recommend always inserting text above prompt-line in
prompt-buffer. This can be done using the `:` mark. However, although
we recommend it this way it can sometimes get confusing how to do it
best.
Solution:
Provide an api to append text to prompt buffer. This is a common
use-case for things using prompt-buffer.
|
|
Problem: 'jumpoptions' "view" doesn't remember skipcol and may lead to
glitched display with 'smoothscroll'.
Solution: Save skipcol in the mark view. Also make sure skipcol doesn't
exceed line size.
|
|
Problem: undoing after the prompt is changed breaks it (and causes init_prompt
to abort it and append a new one), as the undo history contains the old prompt.
Solution: like submitting, clear the undo buffer. Don't do it in init_prompt if
the line was empty; that may not result in a new prompt, and causes commands
like "S" to lose the history.
As u_save, etc. wasn't being called by prompt_setprompt, undoing after it fixes
the prompt usually gave undesirable results anyway.
Remove the added undo_spec.lua test, as its approach no longer works as a repro,
and finding a new one seems fiddly.
|
|
Problem: prompt_setprompt memory leak/other issues when fixing prompt line for
unloaded buffer, or when ': line number is zero.
Solution: don't fix prompt line for unloaded buffer. Clamp ': lnum above zero.
|
|
Problem: if init_prompt replaces the prompt line at the ': mark, it calls
inserted_bytes with the wrong lnum.
Solution: use the correct lnum. Call appended_lines_mark instead when appending
the prompt at the end.
|
|
Problem: internal error E315 in init_prompt if ': has an invalid line number.
Solution: clamp the line number.
|
|
Problem: heap-buffer-overflow in init_prompt and prompt_setprompt if ': mark has
an invalid column number.
Solution: consider an out-of-bounds column number as a missing prompt.
Remove the check for NULL for old_line, as ml_get_buf can't return NULL.
|
|
Problem:
Currently, if prompt gets changed during user-input with
prompt_setprompt() it only gets reflected in next prompt. And that
behavior is not also consistent. If user re-enters insert mode then the
user input gets discarded and a new prompt gets created with the new
prompt.
Solution:
Handle prompt_setprompt eagerly. Update the prompt display, preserve user input.
|
|
Problem:
Currently, : mark is set in start of prompt-line. But more relevant
location is where the user text starts.
Solution:
Store and update column info on ': just like the line info
|
|
Problem: ml_get_buf_len() does not consider text properties
(zeertzj)
Solution: Store text length excluding text properties length
in addition in the memline
related vim/vim#14123
closes: vim/vim#14133
https://github.com/vim/vim/commit/a72d1be5a9984709fc66f460b443ad4a38506113
--------
Replace ml_line_len with ml_line_textlen to be explicit
that Nvim doesn't currently support Vim's text properties
and Nvim doesn't support lines with "ambiguous" length.
--------
vim-patch:9.1.0153: Text properties corrupted with fo+=aw and backspace
Problem: Text properties corrupted with fo+=aw and backspace
Solution: Allocate line and move text properties
(zeertzjq)
closes: vim/vim#14147
https://github.com/vim/vim/commit/7ac1145fbebb66dfee325dc5265309877d941c4e
vim-patch:9.1.0163: Calling STRLEN() to compute ml_line_textlen when not needed
Problem: Calling STRLEN() to compute ml_line_textlen when not needed.
Solution: Use 0 when STRLEN() will be required and call STRLEN() later.
(zeertzjq)
closes: vim/vim#14155
https://github.com/vim/vim/commit/82e079df814f7372e9579450730062b205449efa
Co-authored-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
|
|
Don't handle cindent in insert_check(). Instead, do that just before
returning from insert_execute() if required.
This also makes the in_cinkeys() change from #12894 unnecessary.
|
|
Technically the current behavior does match documentation. However, the
keys following <Cmd>/K_LUA aren't normally received by vim.on_key()
callbacks either, so it does makes sense to discard them along with the
preceding key.
One may also argue that vim.on_key() callbacks should instead receive
the following keys together with the <Cmd>/K_LUA, but doing that may
cause some performance problems, and even in that case the keys should
still be discarded together.
|
|
**Problem**:
Currently, whenever user get's on prompt-text area we move the user to
end of user-input area. As a result when left/c-left,home keys are
triggered at start of user-input the cursor get's placed at end of
user-input. But this behavior can be jarring and unintuitive also it's
different from previous behavior where it'd just stay at start of
input-area. Also, previously when insert-mode was triggered in
prompt-text with n_a for example then cursor was placed at start of
user-input area not at the end. So, that behavior was also broken.
**Solution:**
Restore previous behavior. Don't force user to end of user-input when
entering insert-mode from readonly section.
|
|
Problem: completion: not triggered after i_Ctrl-W/i_Ctrl-U
Solution: Trigger autocomplete when entering Insert mode
(Girish Palya).
fixes: vim/vim#18535
closes: vim/vim#18543
https://github.com/vim/vim/commit/da2dabc6f740b1ed3397797af8a8b0b2ec02bc31
Co-authored-by: Girish Palya <girishji@gmail.com>
|
|
Problem: May check for concealed lines on invalid line numbers.
Solution: Move checks after line number validation.
|
|
Problem: completion: v9.1.1797 broke Ctrl-Y behaviour
(ddad431, after v9.1.1797)
Solution: Restore correct behaviour (Girish Palya).
closes: vim/vim#18494
https://github.com/vim/vim/commit/f3d0d089074c4517b26ea3d2253eaae36c6212eb
Co-authored-by: Girish Palya <girishji@gmail.com>
|
|
file (#35968)
Problem: Code for handling v: variables in generic eval file.
Solution: Move v: variables to evalvars.c. (Yegappan Lakshmanan,
closes vim/vim#4872)
https://github.com/vim/vim/commit/e5cdf153bcb348c68011b308c8988cea42d6ddeb
Remove direct reference to "vimvars" for following functions:
- assert_error()
- get_vim_var_nr()
- get_vim_var_list()
- get_vim_var_dict()
- get_vim_var_str()
- set_cmdarg()
- set_reg_var()
- set_vcount()
- set_vexception()
- set_vthrowpoint()
- set_vim_var_bool()
- set_vim_var_dict()
- set_vim_var_list()
- set_vim_var_nr()
- set_vim_var_special()
- set_vim_var_string()
- set_vim_var_type()
Reorder functions based on v8.2.4930 for
eval_one_expr_in_str() and eval_all_expr_in_str().
Co-authored-by: Bram Moolenaar <Bram@vim.org>
|
|
Problem: completion: autocompletion can be improved
Solution: Add support for "longest" and "preinsert" in 'autocomplete';
add preinserted() (Girish Palya)
* Add support for "longest" in 'completeopt' when 'autocomplete'
is enabled. (Note: the cursor position does not change automatically
when 'autocomplete' is enabled.)
* Add support for "preinsert" when 'autocomplete' is enabled. Ensure
"preinsert" works the same with and without 'autocomplete'
* introduce the preinserted() Vim script function, useful for defining
custom key mappings.
fixes: vim/vim#18314
closes: vim/vim#18387
https://github.com/vim/vim/commit/c05335082adb21d99d96374779856444a3a0688f
Co-authored-by: Girish Palya <girishji@gmail.com>
|
|
Problem: The ops.c file is too big.
Solution: Move code for dealing with registers to a new file. (Yegappan
Lakshmanan, closes vim/vim#4982)
https://github.com/vim/vim/commit/4aea03eb875613e3eae2125b84f02b7cd898b2f8
Co-authored-by: Bram Moolenaar <Bram@vim.org>
|
|
(#35853)
Problem: completion: 'autocomplete' cannot be enabled per buffer
(Tomasz N)
Solution: Make 'autocomplete' global or local to buffer (Girish Palya)
fixes: vim/vim#18320
closes: vim/vim#18333
https://github.com/vim/vim/commit/0208b3e80a080740ff77a5661d0f65090e317d90
Co-authored-by: Girish Palya <girishji@gmail.com>
|
|
'autocomplete' (#35692)
Problem: complete: preinsert does not work well with preinsert
Solution: Make "preinsert" completeopt value work with autocompletion
(Girish Palya)
This change extends Insert mode autocompletion so that 'preinsert' also
works when 'autocomplete' is enabled.
Try: `:set ac cot=preinsert`
See `:help 'cot'` for more details.
closes: vim/vim#18213
https://github.com/vim/vim/commit/fa6fd41a943e6442c1a2ce6b0a237298b00ecca0
Co-authored-by: Girish Palya <girishji@gmail.com>
|
|
Problem:
insert-mode ctrl-r input is treated like raw user input, which is almost
never useful. This means any newlines in the input are affected by
autoindent, etc., which is:
- slow
- usually breaks the formatting of the input
Solution:
- ctrl-r should be treated like a paste, not user-input.
- does not affect `<c-r>=`, so `<c-r>=@x` can still be used to get the
old behavior.
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
|
|
Problem: completion: autocomplete breaks second completion
(gravndal)
Solution: Fix the autocomplete bug (Girish Palya)
fixes: vim/vim#18044
closes: vim/vim#18068
https://github.com/vim/vim/commit/b4e0bd93a9c09377b684c5bdf12c5c2eeb46aada
Co-authored-by: Girish Palya <girishji@gmail.com>
|
|
Problem: Autocompletion adds delay
(gcanat, char101, after v9.1.1638)
Solution: Temporarily disable autocomplation (Girish Palya).
related: vim/vim#17960
fixes: vim/vim#18022
closes: vim/vim#18048
https://github.com/vim/vim/commit/196c376682f9ebad0d13a8d5458accfb33372537
Co-authored-by: Girish Palya <girishji@gmail.com>
|
|
These are not needed after #35129 but making uncrustify still play nice
with them was a bit tricky.
Unfortunately `uncrustify --update-config-with-doc` breaks strings
with backslashes. This issue has been reported upstream,
and in the meanwhile auto-update on every single run has been disabled.
|
|
Problem: cannot perform autocompletion
Solution: Add the 'autocomplete' option value
(Girish Palya)
This change introduces the 'autocomplete' ('ac') boolean option to
enable automatic popup menu completion during insert mode. When enabled,
Vim shows a completion menu as you type, similar to pressing |i\_CTRL-N|
manually. The items are collected from sources defined in the
'complete' option.
To ensure responsiveness, this feature uses a time-sliced strategy:
- Sources earlier in the 'complete' list are given more time.
- If a source exceeds its allocated timeout, it is interrupted.
- The next source is then started with a reduced timeout (exponentially
decayed).
- A small minimum ensures every source still gets a brief chance to
contribute.
The feature is fully compatible with other |i_CTRL-X| completion modes,
which can temporarily suspend automatic completion when triggered.
See :help 'autocomplete' and :help ins-autocompletion for more details.
To try it out, use :set ac
You should see a popup menu appear automatically with suggestions. This
works seamlessly across:
- Large files (multi-gigabyte size)
- Massive codebases (:argadd thousands of .c or .h files)
- Large dictionaries via the `k` option
- Slow or blocking LSP servers or user-defined 'completefunc'
Despite potential slowness in sources, the menu remains fast,
responsive, and useful.
Compatibility: This mode is fully compatible with existing completion
methods. You can still invoke any CTRL-X based completion (e.g.,
CTRL-X CTRL-F for filenames) at any time (CTRL-X temporarily
suspends 'autocomplete'). To specifically use i_CTRL-N, dismiss the
current popup by pressing CTRL-E first.
---
How it works
To keep completion snappy under all conditions, autocompletion uses a
decaying time-sliced algorithm:
- Starts with an initial timeout (80ms).
- If a source does not complete within the timeout, it's interrupted and
the timeout is halved for the next source.
- This continues recursively until a minimum timeout (5ms) is reached.
- All sources are given a chance, but slower ones are de-prioritized
quickly.
Most of the time, matches are computed well within the initial window.
---
Implementation details
- Completion logic is mostly triggered in `edit.c` and handled in
insexpand.c.
- Uses existing inc_compl_check_keys() mechanism, so no new polling
hooks are needed.
- The completion system already checks for user input periodically; it
now also checks for timer expiry.
---
Design notes
- The menu doesn't continuously update after it's shown to prevent
visual distraction (due to resizing) and ensure the internal list
stays synchronized with the displayed menu.
- The 'complete' option determines priority—sources listed earlier get
more time.
- The exponential time-decay mechanism prevents indefinite collection,
contributing to low CPU usage and a minimal memory footprint.
- Timeout values are intentionally not configurable—this system is
optimized to "just work" out of the box. If autocompletion feels slow,
it typically indicates a deeper performance bottleneck (e.g., a slow
custom function not using `complete_check()`) rather than a
configuration issue.
---
Performance
Based on testing, the total roundtrip time for completion is generally
under 200ms. For common usage, it often responds in under 50ms on an
average laptop, which falls within the "feels instantaneous" category
(sub-100ms) for perceived user experience.
| Upper Bound (ms) | Perceived UX
|----------------- |-------------
| <100 ms | Excellent; instantaneous
| <200 ms | Good; snappy
| >300 ms | Noticeable lag
| >500 ms | Sluggish/Broken
---
Why this belongs in core:
- Minimal and focused implementation, tightly integrated with existing
Insert-mode completion logic.
- Zero reliance on autocommands and external scripting.
- Makes full use of Vim’s highly composable 'complete' infrastructure
while avoiding the complexity of plugin-based solutions.
- Gives users C native autocompletion with excellent responsiveness and
no configuration overhead.
- Adds a key UX functionality in a simple, performant, and Vim-like way.
closes: vim/vim#17812
https://github.com/vim/vim/commit/af9a7a04f18693eee4400dd134135527f4e8cd5f
Co-authored-by: Girish Palya <girishji@gmail.com>
|
|
* fix: ensure :edit can not be use on prompt buffer
* fix: starting editing on prompt-line doesn't put cursor at the end
|
|
Problem: The indent.c file is a bit big.
Solution: Move C-indent code a a new cindent.c file. Move other
indent-related code to indent.c. (Yegappan Lakshmanan,
closes vim/vim#5031)
https://github.com/vim/vim/commit/14c01f83487d5c53192297a710eda2b8a4ab17c9
Co-authored-by: Bram Moolenaar <Bram@vim.org>
|
|
Problem: Ignore functionality is not separated.
Solution: Move indent functionality into a new file. (Yegappan Lakshmanan,
closes vim/vim#3886)
https://github.com/vim/vim/commit/4b47162ccede0b6d9cbb9473ad870220a24fbf54
----
Partial port of v8.1.2127 by porting directly to indent_c.c,
not indent.c.
----
Co-authored-by: Bram Moolenaar <Bram@vim.org>
|
|
|
|
Problem:
Not easy to get user-input in prompt-buffer before the user submits the
input. Under the current system user/plugin needs to read the buffer
contents, figure out where the prompt is, then extract the text.
Solution:
- Add prompt_getinput().
- Extract prompt text extraction logic to a separate function
|
|
Problem: completion: inconsistent ordering with CTRL-P
(zeertzjq)
Solution: reset compl_curr_match when using CTRL-P (Girish Palya)
fixes: vim/vim#17425
closes: vim/vim#17434
https://github.com/vim/vim/commit/5fbe72edda708692dba4286860e727e2e0b778cc
Co-authored-by: Girish Palya <girishji@gmail.com>
|
|
Problem:
Cannot enter multiline prompts in a buftype=prompt buffer.
Solution:
- Support shift+enter (`<s-enter>`) to start a new line in the prompt.
- Pasting multiline text via OS paste, clipboard, "xp, etc.
- A/I in editable region works as usual.
- i/a/A/I outside of editable region moves cursor to end of current
prompt.
- Support undo/redo in prompt buffer.
- Support o/O in prompt buffer.
- Expose prompt location as `':` mark.
|
|
Problem: Screen may be updated by a msg_showcmd event before '"' is
cleared from the screen with register insertion.
Solution: Emit the msg_showcmd event before clearing the '"'.
|
|
Problem: potential buffer underflow in insertchar()
Solution: verify that end_len is larger than zero
(jinyaoguo)
When parsing the end-comment leader, end_len can be zero if
copy_option_part() writes no characters. The existing check
unconditionally accessed lead_end[end_len-1], causing potential
underflow when end_len == 0.
This change adds an end_len > 0 guard to ensure we only index lead_end
if there is at least one character.
closes: vim/vim#17476
https://github.com/vim/vim/commit/82a96e3dc0ee8f45bb0c1fe17a0cec1db7582e8f
Co-authored-by: jinyaoguo <guo846@purdue.edu>
|
|
(#34198)
Problem: not easily possible to complete from register content
Solution: add register-completion submode using i_CTRL-X_CTRL-R
(glepnir)
closes: vim/vim#17354
https://github.com/vim/vim/commit/0546068aaef2b1a40faa2945ef7eba249739f219
|
|
refactor(ui): separate types for allocated grids and viewports
|
|
|
|
Problem: 'showmode' ext_messages state is not cleared after insert_expand mode.
Solution: Replace empty message with more idiomatic way to clear the showmode.
|
|
Problem: too many strlen() calls in indent.c
Solution: refactor indent.c slightly and remove strlen() calls
(John Marriott)
closes: vim/vim#17156
https://github.com/vim/vim/commit/eac45c558e3585ada79bb24a86e8cd343e2807cf
Co-authored-by: John Marriott <basilisk@internode.on.net>
|
|
Problem:
When doing paste operation mouse code tries to figure out it it is
dealing with a multi-line register by calling yank_register_mline(),
which fetches register data and checks its type. Later the code calls
either do_put() or insert_reg() which fetch register data again. This is
unnoticeable when working with internal neovim registers, but starts
hurting when dealing with clipboards, especially remote one (forwarded X
or socket tunnel or similar).
Solution:
Change yank_register_mline() to also return pointer to the
register structure prepared for pasting, and insert_reg() to accept
such register pointer and use it if it is supplied. do_put() already
has support for accepting a register structure to be used for pasting.
Fixes #33493
|
|
Problem: When switching to another window or tab page while the
completion menu is active, the menu stays visible, although it
belongs to the previous window/tab page context (Evgeni
Chasnovski).
Solution: Track the window and tab page where completion started. Detect
changes in the main editing loop and cancel completion mode if
the current window or tab page differs from where completion
started.
fixes: vim/vim#17090
closes: vim/vim#17101
https://github.com/vim/vim/commit/cf7f01252f00061876f7eb14dbf74342a55a13a1
Co-authored-by: glepnir <glephunter@gmail.com>
|
|
Problem: string length wrong in get_last_inserted_save()
(after v9.1.1222)
Solution: when removing trailing ESC, also decrease the string length
(Christ van Willegen)
closes: vim/vim#16961
https://github.com/vim/vim/commit/583f5aee96940c29ba17ffb87f1ddf56741b72ba
Co-authored-by: Christ van Willegen <cvwillegen@gmail.com>
|
|
'autoindent' (#32976)
Problem: Wrong cursor position and '^' mark when leaving Insert mode
just after 'autoindent' and cursor on last char of line.
Solution: Don't move cursor to NUL when it wasn't moved to the left
(zeertzjq).
fixes: vim/vim#15581
related: neovim/neovim#30165 neovim/neovim#32943
closes: vim/vim#16922
https://github.com/vim/vim/commit/a3a7d10bfb9547991e04bcf12d1391deb8060754
|
|
Problem: using wrong length for last inserted string
(Christ van Willegen, after v9.1.1212)
Solution: use the correct length in get_last_insert_save(), make
get_last_insert() return a string_T (John Marriott)
closes: vim/vim#16921
https://github.com/vim/vim/commit/8ac0f73eb1e0e6128dd21eb294d12b83b615f05a
N/A patches:
vim-patch:9.1.1129: missing out-of-memory test in buf_write()
vim-patch:9.1.1218: missing out-of-memory check in filepath.c
Co-authored-by: John Marriott <basilisk@internode.on.net>
|
|
Problem: Pasting the '.' register multiple times may work incorrectly
when the last insert starts with Ctrl-D and ends with '0'.
(after 9.1.1212)
Solution: Restore the missing assignment (zeertzjq).
closes: vim/vim#16908
https://github.com/vim/vim/commit/61b354442418539056cc7073a9aec353d297836c
|
|
Problem: too many strlen() calls in edit.c
Solution: refactor edit.c and remove strlen() calls
(John Marriott)
This commit attempts to make edit.c more efficient by:
- in truncate_spaces() pass in the length of the string.
- return a string_T from get_last_insert(), so that the length of the
string is available to the caller.
- refactor stuff_insert():
- replace calls to stuffReadbuff() (which calls STRLEN() on it's
string argument) with stuffReadbuffLen() (which gets the length of
it's string argument passed in).
- replace call to vim_strrchr() which searches from the start of the
string with a loop which searches from end of the string to find the
last ESC character.
- change get_last_insert_save() to call get_last_insert() to get the
last_insert string (the logic is in one place).
closes: vim/vim#16863
https://github.com/vim/vim/commit/34954972c27244a4a1fb4eeeae2aa4e021efd100
Co-authored-by: John Marriott <basilisk@internode.on.net>
|
