Vim

Fork

patch 9.0.2047: perl: warning about inconsistent dll linkage

Commit: https://github.com/vim/vim/commit/2b126a6892b485bc9924464fabdf2313e1100aa9
Author: Ken Takata <kentkt@csc.jp>
Date: Wed Oct 18 11:59:44 2023 +0200

patch 9.0.2047: perl: warning about inconsistent dll linkage

Problem: perl: warning about inconsistent dll linkage
Solution: suppress warning

Suppress warning C4273 (inconsistent DLL linkage).

Also adjust inconsistent use of const.

closes: #13369

Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Ken Takata <kentkt@csc.jp>

Added tag v9.0.2046 for changeset b2075b2d2cca2b48d562d56f76fc30af41dc8422

patch 9.0.2046: win32,python: warning that MS_WIN64 got re-defined

Commit: https://github.com/vim/vim/commit/436f39390f0a5d4c4877edcf69b469987d706f3c
Author: Ken Takata <kentkt@csc.jp>
Date: Wed Oct 18 11:53:30 2023 +0200

patch 9.0.2046: win32,python: warning that MS_WIN64 got re-defined

Problem: win32,python: warning that MS_WIN64 got re-defined
Solution: Do not define MS_WIN64, as it is no longer used

Suppress the following warning:
```
In file included from C:/Python312-64/include/Python.h:12,
from if_python3.c:79:
C:/Python312-64/include/pyconfig.h:240: warning: "MS_WIN64" redefined
240 | #define MS_WIN64
|
<command-line>: note: this is the location of the previous definition
```

`MS_WIN64` is not defined in `Make_mvc.mak` either.
This should be able to be safely removed.

closes: #13370

Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Ken Takata <kentkt@csc.jp>

Added tag v9.0.2045 for changeset 5eab5c00bb7c99d97772514b0fc9e5089339c087

patch 9.0.2045: tests: checking for swap files takes time

Commit: https://github.com/vim/vim/commit/a0e1f06f04da3444e278ddf47e2ea3d5857a7dec
Author: zeertzjq <zeertzjq@outlook.com>
Date: Wed Oct 18 11:50:37 2023 +0200

patch 9.0.2045: tests: checking for swap files takes time

Problem: tests: checking for swap files takes time
Solution: don't check for swap files when test has been skipped

Check for swap files takes a considerable about of time, so don't do
that for skipped tests to avoid wasting time.

closes: #13371

Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: zeertzjq <zeertzjq@outlook.com>

Added tag v9.0.2044 for changeset 28605af12602a55eddf240d738716db31205ae90

patch 9.0.2044: Vim9: exceptions confuse defered functions

Commit: https://github.com/vim/vim/commit/0672595fd50e9ae668676a40e28ebf66d7f52392
Author: Yegappan Lakshmanan <yegappan@yahoo.com>
Date: Wed Oct 18 11:47:37 2023 +0200

patch 9.0.2044: Vim9: exceptions confuse defered functions

Problem: Vim9: exceptions confuse defered functions
Solution: save and restore exception state when calling defered
functions

closes: #13364
closes: #13372

Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>

runtime(systemd): allow for overriding systemd ftplugin settings (#13373)

Commit: https://github.com/vim/vim/commit/5036e698520b2c39e4df5738f026a68ba2e76fef
Author: Enno <Konfekt@users.noreply.github.com>
Date: Wed Oct 18 11:38:19 2023 +0200

runtime(systemd): allow for overriding systemd ftplugin settings (https://github.com/vim/vim/issues/13373)

closes: https://github.com/vim/vim/issues/13357

Signed-off-by: Christian Brabandt <cb@256bit.org>

Added tag v9.0.2043 for changeset 1fcb7c9dc5465f30ec1e96af517c012407f7d448

patch 9.0.2043: Vim9: issue with funcref assignmentand varargs

Commit: https://github.com/vim/vim/commit/96952b2e98cb5f05bc3b3adfb0029056f39cffef
Author: Ernie Rael <errael@raelity.com>
Date: Tue Oct 17 18:15:01 2023 +0200

patch 9.0.2043: Vim9: issue with funcref assignmentand varargs

Problem: Vim9: issue with funcref assignmentand varargs
Solution: Fix funcref type checking

closes: #13351

Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Ernie Rael <errael@raelity.com>

Added tag v9.0.2042 for changeset 8e6ccb8cf55668b8ee1164833392e8e6e5897f97

patch 9.0.2042: Test_cq_zero_exmode fails without channel feature

Commit: https://github.com/vim/vim/commit/c290009e99405024a0d91ec7fab21ac7111c421b
Author: Christian Brabandt <cb@256bit.org>
Date: Tue Oct 17 18:10:13 2023 +0200

patch 9.0.2042: Test_cq_zero_exmode fails without channel feature

Problem: Test_cq_zero_exmode fails without channel feature
Solution: Make the test check the channel feature

closes: #13365

Signed-off-by: Christian Brabandt <cb@256bit.org>

Added tag v9.0.2041 for changeset e9c70470fe945ff904daa53c2867ac947199e557

patch 9.0.2041: trim(): hard to use default mask

Commit: https://github.com/vim/vim/commit/8079917447e7436dccc2e4cd4a4a56ae0a4712f2
Author: Illia Bobyr <illia.bobyr@gmail.com>
Date: Tue Oct 17 18:00:50 2023 +0200

patch 9.0.2041: trim(): hard to use default mask

Problem: trim(): hard to use default mask (partly revert v9.0.2040)
Solution: use default mask when it is empty

The default 'mask' value is pretty complex, as it includes many
characters. Yet, if one needs to specify the trimming direction, the
third argument, 'trim()' currently requires the 'mask' value to be
provided explicitly.

Currently, an empty 'mask' will make 'trim()' call return 'text' value
that is passed in unmodified. It is unlikely that someone is using it,
so the chances of scripts being broken by this change are low.

Also, this reverts commit 9.0.2040 (which uses v:none for the default
and requires to use an empty string instead).

closes: #13358

Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Illia Bobyr <illia.bobyr@gmail.com>

runtime(json5): include syntax script for json5 (#13356)

Commit: https://github.com/vim/vim/commit/5a33ce2a661fb836d4c5c489f2a850172a23e0b0
Author: Rolf Vidar Mazunki Hoksaas <32819373+mazunki@users.noreply.github.com>
Date: Tue Oct 17 11:13:06 2023 +0200

runtime(json5): include syntax script for json5 (https://github.com/vim/vim/issues/13356)

Merging syntax file from gutenye/json5.vim, modified to include proper
vim header.

See: https://github.com/vim/vim/issues/8499

Signed-off-by: Mazunki Hoksaas <rolferen@gmail.com>
Co-authored-by: Guten Ye <ywzhaifei@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>

Added tag v9.0.2040 for changeset 288da62613ba97c17ce63e2683bf8fe2015cb94e

patch 9.0.2040: trim(): hard to use default mask

Commit: https://github.com/vim/vim/commit/6e6386716f9494ae86027c6d34f657fd03dfec42
Author: Illia Bobyr <illia.bobyr@gmail.com>
Date: Tue Oct 17 11:09:45 2023 +0200

patch 9.0.2040: trim(): hard to use default mask

Problem: trim(): hard to use default mask
Solution: Use default 'mask' when it is v:none

The default 'mask' value is pretty complex, as it includes many
characters. Yet, if one needs to specify the trimming direction, the
third argument, 'trim()' currently requires the 'mask' value to be
provided explicitly.

'v:none' is already used to mean "use the default argument value" in
user defined functions. See |none-function_argument| in help.

closes: #13363

Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Illia Bobyr <illia.bobyr@gmail.com>

Added tag v9.0.2039 for changeset efe4751b93b1031a48c74e1d9db5e945131d66c3

patch 9.0.2039: completion shows current word after completion restart

Commit: https://github.com/vim/vim/commit/2e3cd52fa02b1a208c97992b1bca3b04f7be66d4
Author: nwounkn <nwounkn@gmail.com>
Date: Tue Oct 17 11:05:38 2023 +0200

patch 9.0.2039: completion shows current word after completion restart

Problem: completion shows current word after completion restart
Solution: remove the word being completed after completion restart

The word being completed is shown in a completion list after completion
restart, because it isn't removed from the current buffer before
searching for matches.

Also adjust `Test_complete_add_onechar` to match the new behavior.

closes: #13349

Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: nwounkn <nwounkn@gmail.com>

Added tag v9.0.2038 for changeset c470d4fd5eba0e89cd128b3c24a124d6d0a2494e

patch 9.0.2038: Vim9: object method funcref not cleaned up after use

Commit: https://github.com/vim/vim/commit/f3eac695bfe3453fe2a8b980601c55835406f14b
Author: Yegappan Lakshmanan <yegappan@yahoo.com>
Date: Tue Oct 17 11:00:45 2023 +0200

patch 9.0.2038: Vim9: object method funcref not cleaned up after use

Problem: Vim9: object method funcref not cleaned up after use
Solution: Clean up type stack after using object method funcref,
remove now longer used ISN_DEFEROBJ instrunction

closes: #13360

Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>

Added tag v9.0.2037 for changeset e628d7f037589efeaaed2295575e7a3e810a09cd

patch 9.0.2037: A few remaining cmdline completion issues with C-E/Y

Commit: https://github.com/vim/vim/commit/209ec90b9b9bd948d76511c9cd2b17f47a97afe6
Author: Yee Cheng Chin <ychin.git@gmail.com>
Date: Tue Oct 17 10:56:25 2023 +0200

patch 9.0.2037: A few remaining cmdline completion issues with C-E/Y

Problem: A few remaining cmdline completion issues with C-E/Y
Solution: Fix cmdline completion fuzzy/Ctrl-E/Ctrl-Y/options when not
used at the end

Fix cmdline completion fuzzy/Ctrl-E/Ctrl-Y/options when not used at the end

A few places in the cmdline completion code only works properly when the
user hits Tab (or 'wildchar') at the end of the cmdline, even though
it's supposed to work even in the middle of the line.

For fuzzy search, `:e ++ff`, and `:set hl=`, fix completion code to make
sure to use `xp_pattern_len` instead of assuming the entire `xp_pattern`
is the search pattern (since it contains texts after the cursor).

Fix Ctrl-E / Ctrl-Y to not jump to the end when canceling/accepting a
wildmenu completion. Also, make them work even when not using
`set wildoptions+=pum` as there is no drawback to doing so.
(Related issue where this was brought up: #13331)

closes: #13362

Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>

Added tag v9.0.2036 for changeset 123acdc8e64c5824f19a10f606a7399b07f60282

patch 9.0.2036: if_python: rework python3.12 build dependency

Commit: https://github.com/vim/vim/commit/396058acd0cc66e5071d052e03d2067b134952af
Author: Yee Cheng Chin <ychin.git@gmail.com>
Date: Tue Oct 17 10:38:11 2023 +0200

patch 9.0.2036: if_python: rework python3.12 build dependency

Problem: if_python: rework python3.12 build dependency
(after 9.0.1996)
Solution: use PyTuple_Size instead of inlining the Py_SIZE
into the Vim code base

Use a simpler fix for Python 3.12 build issues

Python 3.12 introduced link dependencies to their `Py_SIZE()` inline
function, which #13290 fixed by copying the inline function to Vim's
Python binding code. This works but it's fragile, as a future update may
change the implementation of `Py_SIZE` and there is no way for us to
know.

The reason we need `Py_SIZE` to begin with is that we use
`PyTuple_GET_SIZE()` which calls that. Just fix it by mapping that to
(confusingly similarly named) `PyTuple_Size()`, which we already do in
the stable ABI implementation. There's a minor performance cost in that
it's not inlined and it does error checking but that's fine as we only
call this function rarely (in an error handler).

related: #13290
closes: #13359

Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>

Added tag v9.0.2035 for changeset 403d57b06231db71724ffdb202bd5b4db1d9c6db

patch 9.0.2035: [security] use-after-free with wildmenu

Commit: https://github.com/vim/vim/commit/8f4fb007e4d472b09ff6bed9ffa485e0c3093699
Author: Yee Cheng Chin <ychin.git@gmail.com>
Date: Tue Oct 17 10:06:56 2023 +0200

patch 9.0.2035: [security] use-after-free with wildmenu

Problem: [security] use-after-free with wildmenu
Solution: properly clean up the wildmenu when exiting

Fix wildchar/wildmenu/pum memory corruption with special wildchar's

Currently, using `wildchar=<Esc>` or `wildchar=<C-\>` can lead to a
memory corruption if using wildmenu+pum, or wrong states if only using
wildmenu. This is due to the code only using one single place inside the
cmdline process loop to perform wild menu clean up (by checking
`end_wildmenu`) but there are other odd situations where the loop could
have exited and we need a post-loop clean up just to be sure. If the
clean up was not done you would have a stale popup menu referring to
invalid memory, or if not using popup menu, incorrect status line (if
`laststatus=0`).

For example, if you hit `<Esc>` two times when it's wildchar, there's a
hard-coded behavior to exit command-line as a failsafe for user, and if
you hit `<C-\><C-\><C-N>` it will also exit command-line, but the clean
up code would not have hit because of specialized `<C-\>` handling.

Fix Ctrl-E / Ctrl-Y to not cancel/accept wildmenu if they are also
used for 'wildchar'/'wildcharm'. Currently they don't behave properly,
and also have potentially memory unsafe behavior as the logic is
currently not accounting for this situation and try to do both.
(Previous patch that addressed this: #11677)

Also, correctly document Escape key behavior (double-hit it to escape)
in wildchar docs as it's previously undocumented.

In addition, block known invalid chars to be set in `wildchar` option,
such as Ctrl-C and `<CR>`. This is just to make it clear to the user
they shouldn't be set, and is not required for this bug fix.

closes: #13361

Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>

Added tag v9.0.2034 for changeset 1f154b010b6693f5e938dfc9b4c2cd2cd9a86b37

patch 9.0.2034: don't try to copy SMACK attribute, when none exist

Commit: https://github.com/vim/vim/commit/5a679b2263f597950f99c60a99d4d1a192e9f639
Author: Christian Brabandt <cb@256bit.org>
Date: Mon Oct 16 10:17:13 2023 +0200

patch 9.0.2034: don't try to copy SMACK attribute, when none exist

Problem: don't try to copy SMACK attribute, when none exist
Solution: return early if SMACK extended attributes do not exist or
if they are not supported

closes: #1711
closes: #13348

Signed-off-by: Christian Brabandt <cb@256bit.org>

patch 9.0.2033: gcc overflow-warning for f_resolve

Commit: https://github.com/vim/vim/commit/215c3261a25f7a99e8711a3b3c6158119c6aea9e
Author: Ken Takata <kentkt@csc.jp>
Date: Mon Oct 16 09:57:43 2023 +0200

patch 9.0.2033: gcc overflow-warning for f_resolve

Problem: gcc overflow-warning for f_resolve
Solution: use pointer p instead of pointer q[-1]

Suppress the following warning:
```
filepath.c: In function ‘f_resolve’:
filepath.c:2162:27: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
2162 | q[-1] = NUL;
```

Closes: #13352
closes: #13353

Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Ken Takata <kentkt@csc.jp>