aboutsummaryrefslogtreecommitdiff
path: root/src/nvim/eval/funcs.c
Commit message (Collapse)AuthorAge
* feat(userregfunc): programmable user-defined registers with multibyte supportJosh Rahm2025-04-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch introduces a new global option `userregfunc`, allowing users to define custom behavior for registers not handled by Neovim internally. This enables programmable registers using any Unicode character — including multibyte characters. - A new register slot `USER_REGISTER` is introduced. Any register not matching the standard set (`0-9a-zA-Z"+-*%#/:.=`, etc.) is routed through this system. - When such a register is accessed, the function defined in `userregfunc` is called with three arguments: 1. `{action}` (string): either `"yank"` or `"put"` 2. `{register}` (string): UTF-8 character name of the register 3. `{content}`: - If `action == "yank"`: a dictionary with these keys: - `lines` (list of strings): the yanked text - `type` (string): one of `"v"` (charwise), `"V"` (linewise), or `"b"` (blockwise) - `width` (number, optional): present if `type == "b"` - `additional_data` (dict, optional): user-extensible metadata - If `action == "put"`: this is always `v:null` - The function may return either: - A **string** (used as a charwise register), or - A **dictionary** matching the structure above - Internally, `read_userregister()` and `write_userregister()` convert between `yankreg_T` and typval dictionaries. - Messages and internal logic fully support multibyte register names via UTF-8. - A new `USER_REGISTER` slot is used for logical separation in the register table. Included in this patch is an extensible Lua framework (`vim.userregs`) for defining user register handlers in Lua. It provides per-register handlers via `register_handler(registers, handler)` The global function `_G.def_userreg_func` is registered as the default implementation of `'userregfunc'`, enabling seamless integration with the Lua framework. - Register `λ` dynamically inserts the current date - Register `&` reads and writes from a "global register" file under `stdpath("run")` - Register `?` returns the result of a shell command - Registers that auto-adjust based on filetype, cursor context, or Treesitter nodes This change expands the register model into a programmable abstraction — fully scriptable and extensible — without breaking compatibility.
* refactor(eval): move diff functions to diff.c (#33085)zeertzjq2025-03-27
| | | | They were moved in Vim in patch 8.1.1989. This change is required to port patch 9.1.1243.
* fix(messages): incorrect error message splitting and kind #32990luukvbaal2025-03-19
| | | | | | | | | Problem: Message kind logic for emitting an error message is convoluted and still results in emitting an unfinished message earlier than wanted. Solution: Ensure emsg_multiline() always sets the kind wanted by the caller and doesn't isn't unset to logic for emitting the source message. Caller is responsible for making sure multiple message chunks are not emitted as multiple events by setting `msg_ext_skip_flush`...
* docs: misc #32959Justin M. Keyes2025-03-18
|
* fix(messages): no trailing newline for inputlist, tselect, z= with ext_messagesLuuk van Baal2025-03-13
| | | | | | | | | | Problem: Various list commands end in a newline to go to a new line on the message grid for the prompt message, which is unwanted with ext_messages. Solution: Don't emit a trailing newline with ext_messages for inputlist(), :tselect and z=. Co-authored-by: Tomasz N <przepompownia@users.noreply.github.com>
* refactor(multiqueue): rename multiqueue_new_parent #32767Justin M. Keyes2025-03-08
|
* feat(messages): confirm kind for z=, :tselect, inputlist() #32521luukvbaal2025-02-20
| | | | | | | | | | | Problem: Messages preceding a `cmdline_show->prompt` event can not be distinguished as such when receiving the event. (But since `msg_show` handlers should be scheduled, one can already check whether a prompt is active when displaying the message.) Solution: Rather than add a new kind again, use the `confirm` kind. Could be seen as slightly misleading where it is more of a choice rather than a confirmation, but that already applies to `confirm()` as well...
* vim-patch:9.1.1081: has('bsd') is true for GNU/Hurdzeertzjq2025-02-07
| | | | | | | | | | | | | | | | Problem: has('bsd') is true for GNU/Hurd Solution: exclude GNU/Hurd from BSD feature flag (Zhaoming Luo) GNU/Hurd, like Mac OS X, is a BSD-based system. It should exclude has('bsd') feature just like what Mac OS X does. The __GNU__ pre-defined macro indicates it's compiled for GNU/Hurd. closes: vim/vim#16580 https://github.com/vim/vim/commit/a41dfcd55b1744b44a47d2fc3feb5d5f6207a556 Co-authored-by: Zhaoming Luo <zhmingluo@163.com>
* vim-patch:9.1.1017: Vim9: Patch 9.1.1013 causes a few problemszeertzjq2025-01-16
| | | | | | | | | | | | | | | Problem: Vim9: Patch 9.1.1013 causes a few problems Solution: Translate the function name only when it is a string (Yegappan Lakshmanan) fixes: vim/vim#16453 closes: vim/vim#16450 https://github.com/vim/vim/commit/9904cbca4132f7376246a1a31305eb53e9530023 Cherry-pick call() change from patch 9.0.0345. Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
* vim-patch:9.1.1013: Vim9: Regression caused by patch v9.1.0646zeertzjq2025-01-16
| | | | | | | | | | | | | | | | Problem: Vim9: Regression caused by patch v9.1.0646 Solution: Translate the function name before invoking it in call() (Yegappan Lakshmanan) fixes: vim/vim#16430 closes: vim/vim#16445 https://github.com/vim/vim/commit/6289f9159102e0855bedc566636b5e7ca6ced72c N/A patch: vim-patch:8.2.4176: Vim9: cannot use imported function with call() Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
* feat(ui)!: emit prompt "messages" as cmdline events #31525luukvbaal2025-01-02
| | | | | | | Problem: Prompts are emitted as messages events, where cmdline events are more appropriate. The user input is also emitted as message events in fast context, so cannot be displayed with vim.ui_attach(). Solution: Prompt for user input through cmdline prompts.
* fix(jobs): do not block UI when jobwait() doesn't block (#31803)Gregory Anders2025-01-01
|
* refactor(eval): move funcs to deprecated.c #31650Justin M. Keyes2024-12-23
|
* refactor: iwyu #31637Justin M. Keyes2024-12-23
| | | Result of `make iwyu` (after some "fixups").
* feat(jobs): jobstart(…,{term=true}), deprecate termopen() #31343Justin M. Keyes2024-12-19
| | | | | | | | | | | | Problem: `termopen` has long been a superficial wrapper around `jobstart`, and has no real purpose. Also, `vim.system` and `nvim_open_term` presumably will replace all features of `jobstart` and `termopen`, so centralizing the logic will help with that. Solution: - Introduce `eval/deprecated.c`, where all deprecated eval funcs will live. - Introduce "term" flag of `jobstart`. - Deprecate `termopen`.
* refactor(wininfo): change wininfo from a linked list to an arraybfredl2024-12-16
| | | | | | | | | | "wininfo" is going to be my next victim. The main problem with wininfo is that it is "all or nothing", i e either all state about a buffer in a window is considered valid or none of it is. This needs to be fixed to address some long running grievances. For now this is just a warmup: refactor it from a linked list to a vector.
* fix(messages): more ext_messages kinds #31279luukvbaal2024-11-20
| | | | Add kinds for various commands that output a list, the 'wildmode' list, and for number prompts.
* vim-patch:9.1.0870: too many strlen() calls in eval.c (#31267)zeertzjq2024-11-19
| | | | | | | | | | | Problem: too many strlen() calls in eval.c Solution: Refactor eval.c to remove calls to STRLEN() (John Marriott) closes: vim/vim#16066 https://github.com/vim/vim/commit/bd4614f43d0eac4aff743132bab8e53b015ac801 Co-authored-by: John Marriott <basilisk@internode.on.net>
* refactor(highlight): make enum of builtin highlights start with 1bfredl2024-11-13
| | | | | This makes it possible to use HLF_ values directly as highlight id:s and avoids +1 adjustments especially around messages.
* vim-patch:9.1.0822: topline might be changed in diff mode unexpectedly (#30988)zeertzjq2024-10-30
| | | | | | | | | | | | | Problem: topline might be changed in diff mode unexpectedly (Jaehwang Jung) Solution: do not re-calculate topline, when using line() func in diff mode. fixes: vim/vim#15812 closes: vim/vim#15950 https://github.com/vim/vim/commit/05a40e07c2f0e41b708c4c75a6aa7d0e7f6201a3 Co-authored-by: Christian Brabandt <cb@256bit.org>
* refactor(api)!: rename Dictionary => DictJustin M. Keyes2024-09-23
| | | | | | | | | | | | | | In the api_info() output: :new|put =map(filter(api_info().functions, '!has_key(v:val,''deprecated_since'')'), 'v:val') ... {'return_type': 'ArrayOf(Integer, 2)', 'name': 'nvim_win_get_position', 'method': v:true, 'parameters': [['Window', 'window']], 'since': 1} The `ArrayOf(Integer, 2)` return type didn't break clients when we added it, which is evidence that clients don't use the `return_type` field, thus renaming Dictionary => Dict in api_info() is not (in practice) a breaking change.
* refactor: rename "process" => "proc" #30387Justin M. Keyes2024-09-15
| | | | | | | | | | | | Problem: - "process" is often used as a verb (`multiqueue_process_events`), which is ambiguous for cases where it's used as a topic. - The documented naming convention for processes is "proc". - `:help dev-name-common` - Shorter is better, when it doesn't harm readability or discoverability. Solution: Rename "process" => "proc" in all C symbols and module names.
* fix(startup): server fails if $NVIM_APPNAME is relative dir #30310Justin M. Keyes2024-09-08
| | | | | | | | | | | | | | | | | | Problem: If $NVIM_APPNAME is a relative dir path, Nvim fails to start its primary/default server, and `v:servername` is empty. Root cause is d34c64e342dfba9248d1055e702d02620a1b31a8, but this wasn't noticed until 96128a5076b7 started reporting the error more loudly. Solution: - `server_address_new`: replace slashes "/" in the appname before using it as a servername. - `vim_mktempdir`: always prefer the system-wide top-level "nvim.user/" directory. That isn't intended to be specific to NVIM_APPNAME; rather, each *subdirectory* ("nvim.user/xxx") is owned by each Nvim instance. Nvim "apps" can be identified by the server socket(s) stored in those per-Nvim subdirs. fix #30256
* refactor: extract eval/fs.c from eval/funcs.c (#29985)zeertzjq2024-08-06
| | | | | | In Vim a lot of filesystem functions have been moved to filepath.c. However, some of these functions actually deal with file contents, and Nvim's filesystem-related functions are spread out in a different way. Therefore, it's better to use a different file for these functions.
* refactor(shada): rework msgpack decoding without msgpack-cbfredl2024-08-05
| | | | | | | This also makes shada reading slightly faster due to avoiding some copying and allocation. Use keysets to drive decoding of msgpack maps for shada entries.
* refactor: move some functions out of eval.c (#29964)zeertzjq2024-08-02
| | | | | | - common_function() has always been in evalfunc.c in Vim - return_register() has always been in evalfunc.c in Vim - get_user_input() was moved to ex_getln.c in Vim 8.1.1957 - tv_get_lnum_buf() was moved to typval.c in Vim 8.2.0847
* vim-patch:9.1.0415: Some functions are not testedzeertzjq2024-07-31
| | | | | | | | | | | | Problem: Some functions are not tested Solution: Add a few more tests, fix a few minor problems (Yegappan Lakshmanan) closes: vim/vim#14789 https://github.com/vim/vim/commit/fe424d13ef6e5486923f23f15bb6951e3079412e Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
* vim-patch:9.1.0547: No way to get the arity of a Vim function (#29638)zeertzjq2024-07-10
| | | | | | | | | | | | | Problem: No way to get the arity of a Vim function (Austin Ziegler) Solution: Enhance get() Vim script function to return the function argument info using get(func, "arity") (LemonBoy) fixes: vim/vim#15097 closes: vim/vim#15109 https://github.com/vim/vim/commit/48b7d05a4f88c4326bd5d7a73a523f2d953b3e51 Co-authored-by: LemonBoy <thatlemon@gmail.com>
* refactor(eval): use uv_random() for init_srand() (#29575)zeertzjq2024-07-05
| | | | | N/A patches for version.c: vim-patch:9.1.0518: initialize the random buffer can be improved vim-patch:9.1.0531: resource leak in mch_get_random()
* vim-patch:9.1.0524: the recursive parameter in the *_equal functions can be ↵zeertzjq2024-07-05
| | | | | | | | | | | | | | | removed (#29572) Problem: the recursive parameter in the *_equal functions can be removed Solution: Remove the recursive parameter in dict_equal(), list_equal() object_equal and tv_equal(). Use a comparison of the static var recursive_cnt == 0 to determine whether or not tv_equal() has been called recursively (Yinzuo Jiang). closes: vim/vim#15070 https://github.com/vim/vim/commit/7ccd1a2e858dbb2ac7fb09971dfcbfad62baa677 Co-authored-by: Yinzuo Jiang <jiangyinzuo@foxmail.com>
* refactor(typval): don't use msgpack_packer for msgpackdump()bfredl2024-06-24
| | | | Step towords completely eliminating msgpack_packer.
* revert: "refactor: use S_LEN macro" (#29319)Lewis Russell2024-06-14
| | | | | revert: "refactor: use S_LEN(s) instead of s, n (#29219)" This reverts commit c37695a5d5f2e8914fff86f3581bed70b4c85d3c.
* refactor: use S_LEN(s) instead of s, n (#29219)James2024-06-11
|
* fixup: apply the change on more filesJames Tirta Halim2024-06-04
|
* vim-patch:9.1.0456: Left shift is incorrect with vartabstop and shiftwidth=0zeertzjq2024-06-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: Left shift is incorrect with vartabstop and shiftwidth=0 Solution: make tabstop_at() function aware of shift direction (Gary Johnson) The problem was that with 'vartabstop' set and 'shiftwidth' equal 0, left shifts using << were shifting the line to the wrong column. The tabstop to the right of the first character in the line was being used as the shift amount instead of the tabstop to the left of that first character. The reason was that the tabstop_at() function always returned the value of the tabstop to the right of the given column and was not accounting for the direction of the shift. The solution was to make tabstop_at() aware of the direction of the shift and to choose the tabtop accordingly. A test was added to check this behavior and make sure it doesn't regress. While at it, also fix a few indentation/alignment issues. fixes: vim/vim#14864 closes: vim/vim#14887 https://github.com/vim/vim/commit/88d4f255b7b7a19bb4f6489e0ad0956e47d51fed Co-authored-by: Gary Johnson <garyjohn@spocom.com>
* refactor: move shared messages to errors.h #26214Justin M. Keyes2024-06-01
|
* vim-patch:9.1.0446: getregionpos() inconsistent for partly-selected ↵zeertzjq2024-05-27
| | | | | | | | | | | | multibyte char (#29032) Problem: getregionpos() behaves inconsistently for a partly-selected multibyte char. Solution: Always use column of the first byte for a partly-selected multibyte char (zeertzjq). closes: vim/vim#14851 https://github.com/vim/vim/commit/ef73374dc3e4bf8104ba31d5b22517f8028b467a
* vim-patch:9.1.0443: Can't use blockwise selection with width for getregion() ↵zeertzjq2024-05-25
| | | | | | | | | | | | (#28985) Problem: Can't use a blockwise selection with a width for getregion(). Solution: Add support for blockwise selection with width like the return value of getregtype() or the "regtype" value of TextYankPost (zeertzjq). closes: vim/vim#14842 https://github.com/vim/vim/commit/afc2295c2201ae87bfbb42d5f5315ad0583ccabf
* vim-patch:8.2.3158: strange error message when using islocked() with a ↵zeertzjq2024-05-24
| | | | | | | | | | | | | number (#28962) Problem: Strange error message when using islocked() with a number. (Yegappan Lakshmanan) Solution: Check that the name is empty. https://github.com/vim/vim/commit/1840a7b4e3577e617f724c9d07ccc78195cc010a Use ll_name_len instead. Co-authored-by: Bram Moolenaar <Bram@vim.org>
* vim-patch:9.1.0441: getregionpos() can't properly indicate positions beyond ↵zeertzjq2024-05-24
| | | | | | | | | | | | | | | | | | | | eol (#28957) Problem: getregionpos() can't properly indicate positions beyond eol. Solution: Add an "eol" flag that enables handling positions beyond end of line like getpos() does (zeertzjq). Also fix the problem that a position still has the coladd beyond the end of the line when its column has been clamped. In the last test case with TABs at the end of the line the old behavior is obviously wrong. I decided to gate this behind a flag because returning positions that don't correspond to actual characters in the line may lead to mistakes for callers that want to calculate the length of the selected text, so the behavior is only enabled if the caller wants it. closes: vim/vim#14838 https://github.com/vim/vim/commit/2b09de910458247b70751928217422c38fd5abf8
* vim-patch:9.1.0433: Wrong yanking with exclusive selection and ve=all (#28933)zeertzjq2024-05-23
| | | | | | | | | | Problem: Wrong yanking with exclusive selection and virtualedit=all, and integer overflow when using getregion() on it. Solution: Set coladd when decreasing column and 'virtualedit' is active. Add more tests for getregion() with 'virtualedit' (zeertzjq). closes: vim/vim#14830 https://github.com/vim/vim/commit/701ad50a9efcf0adfe6d787b606c4e4dbd31f26d
* vim-patch:9.1.0430: getregionpos() doesn't handle one char selection (#28924)zeertzjq2024-05-23
| | | | | | | | | | Problem: getregionpos() doesn't handle one char selection. Solution: Handle startspaces differently when is_oneChar is set. Also add a test for an exclusive charwise selection with multibyte chars (zeertzjq) closes: vim/vim#14825 https://github.com/vim/vim/commit/52a6f348874778cf315b47d9e8b5f818f4b97277
* vim-patch:9.1.0426: too many strlen() calls in search.czeertzjq2024-05-22
| | | | | | | | | | | | | Problem: too many strlen() calls in search.c Solution: refactor code and remove more strlen() calls, use explicit variable to remember strlen (John Marriott) closes: vim/vim#14796 https://github.com/vim/vim/commit/8c85a2a49acf80e4f53ec51e6ff2a5f3830eeddb Co-authored-by: John Marriott <basilisk@internode.on.net>
* vim-patch:9.1.0423: getregionpos() wrong with blockwise mode and multibytezeertzjq2024-05-20
| | | | | | | | | | | | | Problem: getregionpos() wrong with blockwise mode and multibyte. Solution: Use textcol and textlen instead of start_vcol and end_vcol. Handle coladd properly (zeertzjq). Also remove unnecessary buflist_findnr() in add_regionpos_range(), as getregionpos() has already switched buffer. closes: vim/vim#14805 https://github.com/vim/vim/commit/c95e64f41f7f6d1bdc95b047ae9b369743c8637b
* vim-patch:9.1.0395: getregionpos() may leak memory on errorzeertzjq2024-05-20
| | | | | | | | | | | | | Problem: regionpos may leak memory on error, coverity complains about dereferencing Null pointer Solution: free all list pointers (after v9.1.394), return early if buflist_findnr() returns NULL closes: vim/vim#14731 https://github.com/vim/vim/commit/b8ecedce79149ac6b994177e9a68979f86065cb1 Co-authored-by: Christian Brabandt <cb@256bit.org>
* vim-patch:9.1.0394: Cannot get a list of positions describing a regionzeertzjq2024-05-20
| | | | | | | | | | | | | | | Problem: Cannot get a list of positions describing a region (Justin M. Keyes, after v9.1.0120) Solution: Add the getregionpos() function (Shougo Matsushita) fixes: vim/vim#14609 closes: vim/vim#14617 https://github.com/vim/vim/commit/b4757e627e6c83d1c8e5535d4887a82d6a5efdd0 Co-authored-by: Shougo Matsushita <Shougo.Matsu@gmail.com> Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
* vim-patch:9.1.0418: Cannot move to previous/next rare word (#28822)zeertzjq2024-05-18
| | | | | | | | | | | | Problem: Cannot move to previous/next rare word (Colin Kennedy) Solution: Add the ]r and [r motions (Christ van Willegen) fixes: vim/vim#14773 closes: vim/vim#14780 https://github.com/vim/vim/commit/8e4c4c7d87def2b100a5d64dc518ef85d9de8765 Co-authored-by: Christ van Willegen - van Noort <github.com@vanwillegen-vannoort.nl>
* fix(path): avoid chdir() when resolving path (#28799)zeertzjq2024-05-17
| | | | | | | | | | | | | | | | | | | | | | Use uv_fs_realpath() instead. It seems that uv_fs_realpath() has some problems on non-Linux platforms: - macOS and other BSDs: this function will fail with UV_ELOOP if more than 32 symlinks are found while resolving the given path. This limit is hardcoded and cannot be sidestepped. - Windows: while this function works in the common case, there are a number of corner cases where it doesn't: - Paths in ramdisk volumes created by tools which sidestep the Volume Manager (such as ImDisk) cannot be resolved. - Inconsistent casing when using drive letters. - Resolved path bypasses subst'd drives. Ref: https://docs.libuv.org/en/v1.x/fs.html#c.uv_fs_realpath I don't know if the old implementation that uses uv_chdir() and uv_cwd() also suffers from the same problems. - For the ELOOP case, chdir() seems to have the same limitations. - On Windows, Vim doesn't use anything like chdir() either. It uses _wfullpath(), while libuv uses GetFinalPathNameByHandleW().
* vim-patch:9.1.0388: cursor() and getregion() don't handle v:maxcol well (#28602)zeertzjq2024-05-02
| | | | | | | | | Problem: cursor() and getregion() don't handle v:maxcol well. Solution: Add special handling for v:maxcol like setpos() does. (zeertzjq) closes: vim/vim#14698 https://github.com/vim/vim/commit/2ffdae79487cb7e323383eda9ae96c2e9d1625bd
* fix(lua): vim.fn.has('nvim-0.10') in fast context, used by vim.deprecatebfredl2024-04-25
|
generated by cgit (git 2.34.1) at 2026-10-21 11:46:37 +0000