aboutsummaryrefslogtreecommitdiff
path: root/src/nvim/eval
Commit message (Collapse)AuthorAge
...
| * 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:partial:9.1.0411: too long functions in eval.czeertzjq2024-07-31
| | | | | | | | | | | | | | | | | | | | | | | | | | Problem: too long functions in eval.c Solution: refactor functions (Yegappan Lakshmanan) closes: vim/vim#14755 https://github.com/vim/vim/commit/4ceb4dc825854032eed423ec1fc372317d3420bf Skip the eval_expr_typval() changes. Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
| * vim-patch:8.2.3264: Vim9: assign test failszeertzjq2024-07-31
| | | | | | | | | | | | | | | | | | Problem: Vim9: assign test fails. Solution: Add missing change. https://github.com/vim/vim/commit/f24f51d03035379cf3e5b2dccf489a40bc4ca92a Co-authored-by: Bram Moolenaar <Bram@vim.org>
| * vim-patch:9.2.1731: Vim9: cannot use += to append to empty NULL listzeertzjq2024-07-31
| | | | | | | | | | | | | | | | | | Problem: Vim9: cannot use += to append to empty NULL list. Solution: Copy the list instead of extending it. (closes vim/vim#6998) https://github.com/vim/vim/commit/81ed4960482f8baabdd7f95b4d5e39744be88ae7 Co-authored-by: Bram Moolenaar <Bram@vim.org>
| * vim-patch:9.0.0331: cannot use items() on a stringzeertzjq2024-07-30
| | | | | | | | | | | | | | | | | | Problem: Cannot use items() on a string. Solution: Make items() work on a string. (closes vim/vim#11016) https://github.com/vim/vim/commit/3e518a8ec74065aedd67d352c93d6ae6be550316 Co-authored-by: Bram Moolenaar <Bram@vim.org>
| * vim-patch:partial:9.0.0327: items() does not work on a listzeertzjq2024-07-30
| | | | | | | | | | | | | | | | | | | | | | Problem: items() does not work on a list. (Sergey Vlasov) Solution: Make items() work on a list. (closes vim/vim#11013) https://github.com/vim/vim/commit/976f859763b215050a03248dbc2bb62fa5d0d059 Skip CHECK_LIST_MATERIALIZE. Co-authored-by: Bram Moolenaar <Bram@vim.org>
| * vim-patch:9.0.0003: functions are global while they could be local (#29777)zeertzjq2024-07-17
| | | | | | | | | | | | | | | | | | | | | | | | Problem: Functions are global while they could be local. Solution: Add "static". Add a few tests. (Yegappan Lakshmanan, closes vim/vim#10612) https://github.com/vim/vim/commit/ee47eaceaa148e07b566ff420f9a3c2edde2fa34 Omit script_name_after_autoload(), untrans_function_name(): Vim9 script only. Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
| * refactor(declarations): also generate prototypes for functions in headersbfredl2024-07-13
| | | | | | | | | | | | | | | | | | | | | | Before this change, "static inline" functions in headers needed to have their function attributes specified in a completely different way. The prototype had to be duplicated, and REAL_FATTR_ had to be used instead of the public FUNC_ATTR_ names. TODO: need a check that a "header.h.inline.generated.h" file is not forgotten when the first "static inline" function with attributes is added to a header (they would just be silently missing).
| * 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(shada): don't use msgpack_packer for shadabfredl2024-06-27
| | | | | | | | | | Now msgpack-c is never used for packing. The real fun part will be replacing it for unpacking.
| * refactor(typval)!: remove distinction of binary and nonbinary stringsbfredl2024-06-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a breaking change which will make refactor of typval and shada code a lot easier. In particular, code that would use or check for v:msgpack_types.binary in the wild would be broken. This appears to be rarely used in existing plugins. Also some cases where v:msgpack_type.string would be used to represent a binary string of "string" type, we use a BLOB instead, which is vimscripts native type for binary blobs, and already was used for BIN formats when necessary. msgpackdump(msgpackparse(data)) no longer preserves the distinction of BIN and STR strings. This is very common behavior for language-specific msgpack bindings. Nvim uses msgpack as a tool to serialize its data. Nvim is not a tool to bit-perfectly manipulate arbitrary msgpack data out in the wild. The changed tests should indicate how behavior changes in various edge cases.
| * 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.
| * Merge pull request #29278 from bfredl/strcatbfredl2024-06-11
| |\ | | | | | | refactor(memory): use builtin strcat() instead of STRCAT()
| | * refactor(memory): use builtin strcat() instead of STRCAT()bfredl2024-06-11
| | | | | | | | | | | | | | | | | | | | | | | | The latter was mostly relevant with the past char_u madness. NOTE: STRCAT also functioned as a counterfeit "NOLINT" for clint apparently. But NOLINT-ing every usecase is just the same as disabling the check entirely.
| * | 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
* | Merge remote-tracking branch 'upstream/master' into mix_20240309Josh Rahm2024-05-24
|\|
| * 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:8.2.0703: Vim9: closure cannot store value in outer context (#28925)zeertzjq2024-05-23
| | | | | | | | | | | | | | | | | | | | | | Problem: Vim9: closure cannot store value in outer context. Solution: Make storing value in outer context work. Make :disassemble accept a function reference. https://github.com/vim/vim/commit/b68b346e6db6d3f848e0a89905fcd7777b73c5d8 Funcstack is Vim9script-only. Co-authored-by: Bram Moolenaar <Bram@vim.org>
| * 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
| * docs: various fixes (#28208)dundargoc2024-04-30
| | | | | | | | | | | | | | | | | | | | Co-authored-by: Evgeni Chasnovski <evgeni.chasnovski@gmail.com> Co-authored-by: Famiu Haque <famiuhaque@proton.me> Co-authored-by: Gregory Anders <greg@gpanders.com> Co-authored-by: Guilherme Soares <guilhermesoares1970@gmail.com> Co-authored-by: Jannik Buhr <jannik.m.buhr@gmail.com> Co-authored-by: thomaswuhoileong <72001875+thomaswuhoileong@users.noreply.github.com> Co-authored-by: tom-anders <13141438+tom-anders@users.noreply.github.com> Co-authored-by: zeertzjq <zeertzjq@outlook.com>
| * fix(lua): vim.fn.has('nvim-0.10') in fast context, used by vim.deprecatebfredl2024-04-25
| |
| * 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.
| * vim-patch:9.1.0341: Problem: a few memory leaks are found (#28382)zeertzjq2024-04-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: a few memory leaks are found (LuMingYinDetect ) Solution: properly free the memory Fixes the following problems: - Memory leak in f_maplist() fixes: vim/vim#14486 - Memory leak in option.c fixes: vim/vim#14485 - Memory leak in f_resolve() fixes: vim/vim#14484 - Memory leak in f_autocmd_get() related: vim/vim#14474 - Memory leak in dict_extend_func() fixes: vim/vim#14477 fixes: vim/vim#14238 closes: vim/vim#14517 https://github.com/vim/vim/commit/29269a71b5ac8a87c6c4beca35c173a19a2c9398 Co-authored-by: Christian Brabandt <cb@256bit.org>
| * vim-patch:9.1.0335: String interpolation fails for List type (#28364)zeertzjq2024-04-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: String interpolation fails for List type Solution: use implicit string(list) for string interpolation and :put = (Yegappan Lakshmanan) related: vim/vim#14529 closes: vim/vim#14556 https://github.com/vim/vim/commit/bce51d9005dd1c5bc002acbac2e12b649abcb013 Cherry-pick eval_to_string_eap() from patch 8.2.1914. Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
| * vim-patch:9.1.0313: Crash when using heredoc with comment in command blockzeertzjq2024-04-14
| | | | | | | | | | | | | | | | | | | | Problem: Crash when using heredoc with comment in command block. Solution: Handle a newline more like the end of the line, fix coverity warning (zeertzjq). closes: vim/vim#14535 https://github.com/vim/vim/commit/1f5175d9af3d3f37e19f23e0e6f84caec47390f2
| * vim-patch:9.1.0312: heredocs are not supported for :commandszeertzjq2024-04-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: heredocs are not supported for :commands (balki) Solution: Add heredoc support (Yegappan Lakshmanan) fixes: vim/vim#14491 closes: vim/vim#14528 https://github.com/vim/vim/commit/e74cad3321ce1dcefc1fc64f617511275b6cd930 Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
| * vim-patch:9.0.2180: POSIX function name in exarg causes issues (#28308)zeertzjq2024-04-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: POSIX function name in exarg struct causes issues on OpenVMS Solution: Rename getline member in exarg struct to ea_getline, remove isinf() workaround for VMS There are compilers that do not treat well POSIX functions - like getline - usage in the structs. Older VMS compilers could digest this... but the newer OpenVMS compilers ( like VSI C x86-64 X7.4-843 (GEM 50XB9) ) cannot deal with these structs. This could be limited to getline() that is defined via getdelim() and might not affect all POSIX functions in general - but avoiding POSIX function names usage in the structs is a "safe side" practice without compromising the functionality or the code readability. The previous OpenVMS X86 port used a workaround limiting the compiler capabilities using __CRTL_VER_OVERRIDE=80400000 In order to make the OpenVMS port future proof, this pull request proposes a possible solution. closes: vim/vim#13704 https://github.com/vim/vim/commit/6fdb6280821a822768df5689a5d727e37d38306c Co-authored-by: Zoltan Arpadffy <zoltan.arpadffy@gmail.com>
| * vim-patch:9.1.0301: Vim9: heredoc start may be recognized in string (#28266)zeertzjq2024-04-11
| | | | | | | | | | | | | | | | | | Problem: Vim9: heredoc start may be recognized in string. Solution: Don't skip to closing bracket for invalid list assignment. (zeertzjq) closes: vim/vim#14472 https://github.com/vim/vim/commit/1817ccdb107ceeaf5c48fe193da5146682c15ca6
| * vim-patch:9.1.0287: Vim9: comment may be treated as heredoc start (#28257)zeertzjq2024-04-10
| | | | | | | | | | | | | | | | | | | | | | Problem: Vim9: comment may be treated as heredoc start. (Ernie Rael) Solution: Use skip_var_list() instead of find_name_end(). (zeertzjq) fixes: vim/vim#14444 closes: vim/vim#14446 https://github.com/vim/vim/commit/9a91d2b72c20f213bbf77f27b7edd01e0e43d5e0
| * vim-patch:8.2.4395: some code lines not covered by tests (#28248)zeertzjq2024-04-09
| | | | | | | | | | | | | | | | | | Problem: Some code lines not covered by tests. Solution: Add a few more test cases. Fix getting more than one error for invalid assignment. https://github.com/vim/vim/commit/8b716f5f2204f938769de283d43bcb2f77d403e7 Co-authored-by: Bram Moolenaar <Bram@vim.org>
| * vim-patch:8.2.0981: Vim9: cannot compile "[var, var] = list" (#28247)zeertzjq2024-04-09
| | | | | | | | | | | | | | | | Problem: Vim9: cannot compile "[var, var] = list". Solution: Implement list assignment. https://github.com/vim/vim/commit/47a519a933e8bcaf703a5feaac5c01491a658ee3 Co-authored-by: Bram Moolenaar <Bram@vim.org>
| * vim-patch:9.1.0231: Filetype may be undetected when SwapExists sets ft in ↵zeertzjq2024-04-01
| | | | | | | | | | | | | | | | | | | | | | | | other buf (#28136) Problem: Filetype may be undetected when a SwapExists autocommand sets filetype in another buffer. Solution: Make filetype detection state buffer-specific. Also fix a similar problem for 'modified' (zeertzjq). closes: vim/vim#14344 https://github.com/vim/vim/commit/5bf6c2117fcef85fcf046c098dd3eb72a0147859
| * vim-patch:8.2.2318: Vim9: string and list index work differentlyzeertzjq2024-03-23
| | | | | | | | | | | | | | | | | | Problem: Vim9: string and list index work differently. Solution: Make string index work like list index. (closes vim/vim#7643) https://github.com/vim/vim/commit/e7525c552060dd04aacdbca6bb5fe6460cf4da60 Co-authored-by: Bram Moolenaar <Bram@vim.org>