aboutsummaryrefslogtreecommitdiff
path: root/src/nvim/memory.c
Commit message (Collapse)AuthorAge
* feat(multicursor): MC HAMMER #41587Justin M. Keyes2026-09-01
| | | | | | | | | | | | | | | | | | | | | Other (squashed) commits: fix(tui): emit ui_send output atomically with the frame Problem: tui_ui_send() writes directly to the TTY, bypassing the output buffer. Sequences sent via nvim_ui_send() (e.g. kitty multiple-cursors, or visual-dot-repeat) always arrive in a separate TTY write from the frame they were computed for. This manifests as "tearing", or e.g. in the case of multicursor the terminal renders text with stale cursor overlays. Solution: - tui_ui_send(): while a frame is being assembled (pending invalid regions or buffered output), buffer instead of writing directly. - Out-of-frame sends (tty queries, clear-on-disable) still write immediately. - mcursor.lua: emit the terminal-cursor update at the end of the redraw cycle (`on_end`, when screen positions are final) instead of vim.schedule().
* fix(lifecycle): Lua state not freed if free_all_mem() is re-entered #41366Justin M. Keyes2026-08-18
| | | | | | | | | | | | | | | | | | | | | | Problem: Leak reported by ASAN CI, always at Lua state init. ERROR: LeakSanitizer: detected memory leaks strbuf_init src/cjson/strbuf.c:62:22 json_create_config src/cjson/lua_cjson.c:635:5 lua_cjson_new src/cjson/lua_cjson.c:2060:5 nlua_state_add_stdlib src/nvim/lua/stdlib.c:840:3 nlua_state_init src/nvim/lua/executor.c:973:3 ... SUMMARY: AddressSanitizer: 1055 byte(s) leaked in 2 allocation(s). Analysis: `getout()` may run during `free_all_mem()` (that's why it checks `!entered_free_all_mem`). If that happens, the second `os_exit()` returns early from `free_all_mem()` then `exit()` is called and Lua state is never closed. Solution: Always call `nlua_free_all_mem()` in the early-return case.
* feat(input)!: CmdAtom event #41297Justin M. Keyes2026-08-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: There is no unified notion of a "user action". Vim processes input by one-char-at-a-time, and mostly throws away any hints it might gather about the user's action, with one exception: it stores the last _edit_ action (the "redo buffer", encoded as unstructured `["x][v][count]body` bytes). Plugins can only observe individual keys (vim.on_key) and high-level effects (TextChanged, CursorMoved). Solution: - Users can subscribe to `CmdAtom` events to handle any user action. - Event is deferred; handlers cannot cancel or interfere with user actions. - Capture `CmdSpec` from the normal/insert/visual subsystems. - typeahead/readahead stay unstructured (`buffheader_T`): they are key streams, not commands. - the redo/record buffers become `StringBuilder`: fewer allocations/copies. - Repurpose the input/redo engine to accept `CmdSpec` objects. "atom": one repeatable unit of user input, as a resolved (post-mapping) keysequence plus structured fields. Only user actions, not `:normal`, API calls, or non-"t" `feedkeys`. BREAKING: dot-repeat of an Insert session, replays the entire session including cursor-moves (:help ins-repeat). BREAKING: dot-repeat of a Visual operation, replays the selection instead of operating on a fixed-size region.
* refactor(vimscript)!: drop ctxget(), ctxpush(), etc #40724Justin M. Keyes2026-07-13
| | | | | | | | | | Problem: This functions are most likely never used in the wild. - They are redundant with `nvim_get_context` + `nvim_load_context`. - The "context" concept was never fully developed and hasn't gained traction. Solution: Drop these vimscript aliases, they are just extra cruft.
* refactor(insert): rename edit.c => insert.c #40705Justin M. Keyes2026-07-12
| | | | | | | | | | Problem: - `edit.c` is an unnecessarily misleading and less-discoverable name than `insert.c`. - Numerous insert-mode related things are named with a `ins_` prefix. - There is already a `insexpand.c` module... Solution: Rename `edit.c` => `insert.c`.
* refactor(input): rename getchar.c => input.c #40698Justin M. Keyes2026-07-12
| | | | | | | | | | | | Problem: `getchar.c` is a quirky name and doesn't align with our existing `os/input.c` and `tui/input.c` modules, which encompass the same topic at different layers. Solution: Rename `getchar.c` => `input.c` for discoverability. Introduce `dialog.c` for functionality related to showing confirm prompts, dialogs, etc.
* build: update clang v21, fix warningsdundargoc2026-04-14
| | | | | - `src/nvim/ex_cmds_defs.h`: use "U" instead of "u" per `readability-uppercase-literal-suffix`
* vim-patch:9.2.0253: various issues with wrong b_nwindows after closing buffersSean Dewar2026-03-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: close_buffer() callers incorrectly handle b_nwindows, especially after nasty autocmds, allowing it to go out-of-sync. May lead to buffers that can't be unloaded, or buffers that are prematurely freed whilst displayed. Solution: Modify close_buffer() and review its callers; let them decrement b_nwindows if it didn't unload the buffer. Remove some now unneeded workarounds like 8.2.2354, 9.1.0143, 9.1.0764, which didn't always work (Sean Dewar) (endless yapping omitted) related: vim/vim#19728 https://github.com/vim/vim/commit/bf21df1c7bc772e3a29961c961d0821584d50ee0 b_nwindows = 0 change for free_all_mem() was already ported. Originally Nvim returned true when b_nwindows was decremented before the end was reached (to better indicate the decrement). That's not needed anymore, so just return true only at the end, like Vim. (retval isn't used anywhere now anyways) Set textlock for dict watchers at the end of close_buffer() to prevent them from switching windows, as that can leave a window with a NULL buffer. (possible before this PR, but the new assert catches it; added a test) Despite textlock, things still aren't ideal, as watchers may observe the buffer as unloaded and hidden (b_nwindows was decremented), yet still in a window... Likewise, for Nvim, wipe_qf_buffer()'s comment may not be entirely accurate; autocmds are blocked, but on_detach callbacks (textlocked) and dict watchers may still run. Might be problematic, but those aren't new issues. Co-authored-by: Sean Dewar <6256228+seandewar@users.noreply.github.com>
* fix: :ball w_locked check, reset b_nwindows in free_all_mem() #38484Sean Dewar2026-03-25
| | | | | | | | | | | | | | | | | Problem: - Small error in port of v9.1.0678, causing :ball to check w_locked for the wrong window. - After #27439, free_all_mem() may not wipe out buffers that were open in more than one window before windows were freed. Solution: - Check win_locked() for wp in ex_buffer_all(), not curwin. - Set b_nwindows to 0 in free_all_mem() before calling close_buffer(). Ref: https://github.com/neovim/neovim/pull/38473#issuecomment-4125117681 No need to block these fixes on that. free_all_mem() change also looks like it fixed the existing "N lua references were leaked!" warnings on the CI.
* vim-patch:9.1.2147: Compile warning in strings.c (#37842)zeertzjq2026-02-13
| | | | | | | | | | Problem: Compile warning in strings.c Solution: Use const qualifier (John Marriott). closes: vim/vim#19387 https://github.com/vim/vim/commit/388654af27a6e422172d6ee6c40b061f5dd6dfa0 Co-authored-by: John Marriott <basilisk@internode.on.net>
* feat(events): MarkSet event, aucmd_defer() #35793Nathan Smith2025-12-07
| | | | | | | | | | | | Problem: - Can't subscribe to "mark" events. - Executing events is risky because they can't be deferred. Solution: - Introduce `MarkSet` event. - Introduce `aucmd_defer()`. Helped-by: zeertzjq <zeertzjq@outlook.com> Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
* perf(tui): faster implementation of terminfobfredl2025-10-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The processing of terminfo can be separated into two steps: 1. The initialization of terminfo, which includes trying to find $TERM in a terminfo database file. As a fallback, common terminfo definitions are compiled in. After this, we apply a lot of ad-hoc patching to cover over limitations of terminfo. 2. While processing updates from nvim, actually using terminfo strings and formatting them with runtime values. for this part, terminfo essentially is a hyper-enhanced version of snprintf(), including a sm0l stack based virtual machine which can manipulate the runtime parameters. This PR completely replaces libuniblium for step 2, with code vendored from NetBSD's libtermkey which has been adapted to use typesafe input parameters and to write into an output buffer in place. The most immedatiate effects is a performance enhancement of update_attrs() which is a very hot function when profiling the TUI-process part of screen updates. In a stupid microbenchmark (essentially calling nvim__screenshot over and over in a loop) this leads to a speedup of ca 1.5x for redrawing the screen on the TUI-side. What this means in practise when using nvim as a text editor is probably no noticible effect at all, and when reabusing nvim as idk a full screen RGB ASCII art rendrer maybe an increase from 72 to 75 FPS LMAO. As nice side-effect, reduce the usage of unibilium to initialization only.. which will make it easier to remove, replace or make unibilium optional, adressing #31989. Specifically, the builtin fallback doesn't use unibilium at all, so a unibilium-free build is in principle possible if the builtin definitions are good enough. As a caveat, this PR doesn't touch libtermkey at all, which still has a conditional dependency on unibilium. This will be investigated in a follow-up PR Note: the check of $TERMCOLOR was moved from tui/tui.c to _defaults.lua in d7651b27d54a87c5783c0a579af11da9a16a39aa as we want to skip the logic in _defaults.lua if the env var was set, but there is no harm in TUI getting the right value when the TUI is trying to initialize its terminfo shenanigans. Also this check is needed when a TUI connects to a `--headless` server later, which will observe a different $TERMCOLOR value than the nvim core process itself.
* vim-patch:8.1.2077: the ops.c file is too bigJan Edmund Lazo2025-09-26
| | | | | | | | | | 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>
* vim-patch:8.1.1259: crash when exiting early (#35552)Jan Edmund Lazo2025-08-30
| | | | | | | | Problem: Crash when exiting early. (Ralf Schandl) Solution: Only pop/push the title when it was set. (closes vim/vim#4334) https://github.com/vim/vim/commit/e5c83286bb9a72cc686f2826e605eddebe3c730c Co-authored-by: Bram Moolenaar <Bram@vim.org>
* refactor(build): remove INCLUDE_GENERATED_DECLARATIONS guardsbfredl2025-08-14
| | | | | | | | | 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.
* refactor: make two functions used only in memory.c static (#34339)zeertzjq2025-06-06
| | | | After #29450 try_to_free_memory() is only used in memory.c. Also move do_outofmem_msg() closer to where it's used.
* vim-patch:9.1.1435: completion: various flaws in fuzzy completion (#34335)zeertzjq2025-06-06
| | | | | | | | | | | | | | | | | | | | | | | | | Problem: completion: various flaws in fuzzy completion Solution: fix the issues (Girish Palya) - Remove the brittle `qsort()` on `compl_match_array`. - Add a stable, non-recursive `mergesort` for the internal doubly linked list of matches. - The sort now happens directly on the internal representation (`compl_T`), preserving sync with external structures and making sorting stable. - Update fuzzy match logic to enforce `max_matches` limits after sorting. - Remove `trim_compl_match_array()`, which is no longer necessary. - Fixe test failures by correctly setting `selected` index and maintaining match consistency. - Introduce `mergesort_list()` in `misc2.c`, which operates generically over doubly linked lists. - Remove `pum_score` and `pum_idx` variables fixes: vim/vim#17387 closes: vim/vim#17430 https://github.com/vim/vim/commit/8cd42a58b49c948ab59ced6ca5f5ccfae5d9ecea Co-authored-by: Girish Palya <girishji@gmail.com>
* fix(env.c): drop envmap, free os_getenv() result #32683Judit Novak2025-04-16
| | | | | | | | | | | | | | | | | | | | | | Problem: vim.uv.os_setenv gets "stuck" per-key. #32550 Caused by the internal `envmap` cache. #7920 :echo $FOO <-- prints nothing :lua vim.uv.os_setenv("FOO", "bar") :echo $FOO <-- prints bar (as expected) :lua vim.uv.os_setenv("FOO", "fizz") :echo $FOO <-- prints bar, still (not expected. Should be "fizz") :lua vim.uv.os_unsetenv("FOO") :echo $FOO <-- prints bar, still (not expected. Should be nothing) :lua vim.uv.os_setenv("FOO", "buzz") :echo $FOO <-- prints bar, still (not expected. Should be "buzz") Solution: - Remove the `envmap` cache. - Callers to `os_getenv` must free the result. - Update all call-sites. - Introduce `os_getenv_noalloc`. - Extend `os_env_exists()` the `nonempty` parameter.
* refactor(messages): simplify message historyLuuk van Baal2025-03-03
|
* refactor: iwyu #31637Justin M. Keyes2024-12-23
| | | Result of `make iwyu` (after some "fixups").
* docs: misc (#29719)dundargoc2024-08-29
| | | | | | | | | Co-authored-by: Evgeni Chasnovski <evgeni.chasnovski@gmail.com> Co-authored-by: Lauri Heiskanen <lauri.heiskanen@nimble.fi> Co-authored-by: Piotr Doroszewski <5605596+Doroszewski@users.noreply.github.com> Co-authored-by: Tobiasz Laskowski <tobil4sk@outlook.com> Co-authored-by: ariel-lindemann <41641978+ariel-lindemann@users.noreply.github.com> Co-authored-by: glepnir <glephunter@gmail.com> Co-authored-by: zeertzjq <zeertzjq@outlook.com>
* refactor: replace '\0' with NULJames Tirta Halim2024-06-04
|
* Merge pull request #29124 from bfredl/inputringbfredl2024-06-02
|\ | | | | refactor(input): don't use a ring for input
| * refactor(input): don't use a ring for inputbfredl2024-06-01
| | | | | | | | Since paste data is handled via a separate channel, the data processed via `input_buffer` is typically just explicit keys as typed in by the user. Therefore it should be fine to use `memmove()` to always put the remaining data in front when refilling the buffer.
* | refactor: move shared messages to errors.h #26214Justin M. Keyes2024-06-01
|/
* refactor: add function attributes to xmemcpyz() (#28435)zeertzjq2024-04-21
| | | Also attempt to fix the new coverity warning.
* refactor: add xmemcpyz() and use it in place of some xstrlcpy() (#28422)zeertzjq2024-04-20
| | | | | | Problem: Using xstrlcpy() when the exact length of the string to be copied is known is not ideal because it requires adding 1 to the length and an unnecessary strlen(). Solution: Add xmemcpyz() and use it in place of such xstrlcpy() calls.
* refactor(msgpack): allow flushing buffer while packing msgpackbfredl2024-03-07
| | | | | | | | | | | | | | Before, we needed to always pack an entire msgpack_rpc Object to a continous memory buffer before sending it out to a channel. But this is generally wasteful. it is better to just flush whatever is in the buffer and then continue packing to a new buffer. This is also done for the UI event packer where there are some extra logic to "finish" of an existing batch of nevents/ncalls. This doesn't really stop us from flushing the buffer, just that we need to update the state machine accordingly so the next call to prepare_call() always will start with a new event (even though the buffer might contain overflow data from a large event).
* refactor(api): reduce temporary allocations when replacing linesbfredl2024-02-20
| | | | | | | | | | | | | | | The way ml_replace_buf is implemented makes it unfriendly for being used in a loop: every call allocates a scratch buffer for putting the line into the "dirty" state. This then immediately needs to be freed as the next ml_replace_buf and/or ml_append_buf call will flush that buffer. It's better to later pay the price of allocating the scratch buffer only if the line is being immediately edited (likely when using the API to only change one line) with an extra memcpy, than allocating that buffer multiple times every time the API is called. Of course, a separate xmalloc/xfree cycle for each time the dirty line changes is unwanted to begin with. But fixing that is a later refactor.
* fix(exitfree): don't use ex commands to close windows in free_all_mem()bfredl2024-02-12
| | | | | | Attempting to manipulate the window layout via ex commands is not safe here. It is also redundant: `win_free_all()` can free multiple windows by itself perfectly fine.
* refactor(IWYU): fix headersdundargoc2024-01-11
| | | | | | Remove `export` pramgas from defs headers as it causes IWYU to believe that the definitions from the defs headers comes from main header, which is not what we really want.
* refactor: eliminate cyclic includesdundargoc2023-12-20
|
* docs: add style rule regarding initializationdundargoc2023-12-18
| | | | | Specifically, specify that each initialization should be done on a separate line.
* refactor(options): remove option type macrosFamiu Haque2023-12-14
| | | | | | | | Problem: We have `P_(BOOL|NUM|STRING)` macros to represent an option's type, which is redundant because `OptValType` can already do that. The current implementation of option type flags is also too limited to allow adding multitype options in the future. Solution: Remove `P_(BOOL|NUM|STRING)` and replace it with a new `type_flags` attribute in `vimoption_T`. Also do some groundwork for adding multitype options in the future. Side-effects: Attempting to set an invalid keycode option (e.g. `set t_foo=123`) no longer gives an error.
* revert: "memory: Free buffers after freeing variables" (#26356)zeertzjq2023-12-02
| | | | | | | | | This reverts commit fe30d8ccef17fff23676b8670dfec86444e2cb32. The original commit intends to prevent heap-use-after-free with EXITFREE caused by changedtick_di, which is no longer a problem. Freeing buffers after freeing variables will cause heap-use-after-free with EXITFREE when a partial is used as prompt callback.
* refactor: free more reachable memory with EXITFREE (#26349)zeertzjq2023-12-02
| | | Discovered using __sanitizer_print_memory_profile().
* build: don't define FUNC_ATTR_* as empty in headers (#26317)zeertzjq2023-11-30
| | | | | | FUNC_ATTR_* should only be used in .c files with generated headers. Defining FUNC_ATTR_* as empty in headers causes misuses of them to be silently ignored. Instead don't define them by default, and only define them as empty after a .c file has included its generated header.
* refactor: move function macros out of vim_defs.h (#26300)zeertzjq2023-11-29
|
* refactor: move some constants out of vim_defs.h (#26298)zeertzjq2023-11-29
|
* refactor: fix headers with IWYUdundargoc2023-11-28
|
* build(IWYU): fix includes for func_attr.hdundargoc2023-11-27
|
* refactor: move Arena and ArenaMem to memory_defs.h (#26240)zeertzjq2023-11-27
|
* refactor: iwyu (#26062)zeertzjq2023-11-16
|
* build: remove PVSdundargoc2023-11-12
| | | | | | | We already have an extensive suite of static analysis tools we use, which causes a fair bit of redundancy as we get duplicate warnings. PVS is also prone to give false warnings which creates a lot of work to identify and disable.
* refactor(drawline): avoid xmalloc/xfree cycles on each screenlinebfredl2023-11-09
|
* refactor(grid): do arabic shaping in one placebfredl2023-10-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | The 'arabicshape' feature of vim is a transformation of unicode text to make arabic and some related scripts look better at display time. In particular the content of a cell will be adjusted depending on the (original) content of the cells just before and after it. This is implemented by the arabic_shape() function in nvim. Before this commit, shaping was invoked in four different contexts: - when rendering buffer text in win_line() - in line_putchar() for rendering virtual text - as part of grid_line_puts, used by messages and statuslines and similar - as part of draw_cmdline() for drawing the cmdline This replaces all these with a post-processing step in grid_put_linebuf(), which has become the entry point for all text rendering after recent refactors. An aim of this is to make the handling of multibyte text yet simpler. One of the main reasons multibyte chars needs to be "parsed" into codepoint arrays of composing chars is so that these could be inspected for the purpose of shaping. This can likely be vastly simplified in many contexts where only the total length (in bytes) and width of composed char is needed.
* refactor: reorganize option header files (#25437)zeertzjq2023-09-30
| | | | | | - Move vimoption_T to option.h - option_defs.h is for option-related types - option_vars.h corresponds to Vim's option.h - option_defs.h and option_vars.h don't include each other
* build(iwyu): add a few more _defs.h mappings (#25435)zeertzjq2023-09-30
|
* build: remove LOG_LIST_ACTIONS option and related codedundargoc2023-05-28
| | | | It has not been used for a long time and the likelihood of it still working is low.
* refactor(map): avoid duplicated khash_t types for valuesbfredl2023-05-17
| | | | | | | | | | | | | | | | | | | | | This reduces the total number of khash_t instantiations from 22 to 8. Make the khash internal functions take the size of values as a runtime parameter. This is abstracted with typesafe Map containers which are still specialized for both key, value type. Introduce `Set(key)` type for when there is no value. Refactor shada.c to use Map/Set instead of khash directly. This requires `map_ref` operation to be more flexible. Return pointers to both key and value, plus an indicator for new_item. As a bonus, `map_key` is now redundant. Instead of Map(cstr_t, FileMarks), use a pointer map as the FileMarks struct is humongous. Make `event_strings` actually work like an intern pool instead of wtf it was doing before.
generated by cgit (git 2.34.1) at 2026-10-26 15:37:50 +0000