0
0
mirror of https://github.com/vim/vim.git synced 2025-07-26 11:04:33 -04:00

19166 Commits

Author SHA1 Message Date
Christian Brabandt
26c11c5688
patch 9.0.2121: [security]: use-after-free in ex_substitute
Problem:  [security]: use-after-free in ex_substitute
Solution: always allocate memory

closes: #13552

A recursive :substitute command could cause a heap-use-after free in Vim
(CVE-2023-48706).

The whole reproducible test is a bit tricky, I can only reproduce this
reliably when no previous substitution command has been used yet
(which is the reason, the test needs to run as first one in the
test_substitute.vim file) and as a combination of the `:~` command
together with a :s command that contains the special substitution atom `~\=`
which will make use of a sub-replace special atom and calls a vim script
function.

There was a comment in the existing :s code, that already makes the
`sub` variable allocate memory so that a recursive :s call won't be able
to cause any issues here, so this was known as a potential problem
already.  But for the current test-case that one does not work, because
the substitution does not start with `\=` but with `~\=` (and since
there does not yet exist a previous substitution atom, Vim will simply
increment the `sub` pointer (which then was not allocated dynamically)
and later one happily use a sub-replace special expression (which could
then free the `sub` var).

The following commit fixes this, by making the sub var always using
allocated memory, which also means we need to free the pointer whenever
we leave the function. Since sub is now always an allocated variable,
we also do no longer need the sub_copy variable anymore, since this one
was used to indicated when sub pointed to allocated memory (and had
therefore to be freed on exit) and when not.

Github Security Advisory:
https://github.com/vim/vim/security/advisories/GHSA-c8qm-x72m-q53q

Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-11-22 21:52:45 +01:00
Christian Brabandt
4e5c3cf07b
patch 9.0.2120: un-used assignment in do_source_buffer_init
Problem:  un-used assignment in do_source_buffer_init
Solution: Remove it

Coverity warns about assigning NULL to line in scriptfile.c:1408,
because right after that assignment, in the next iteration of the loop,
line will be overwritten by the next value from vim_strsave().

And in case this was the last iteration, the line variable is no longer
used until the function returns. So we can safely remove that assignment.

closes: #13547

Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-11-21 19:59:54 +01:00
Christian Brabandt
6b36645f07
patch 9.0.2119: remove dead-condition in ex_class
Problem:  remove dead-condition in ex_class()
Solution: remove the extra condition

The variable is_class must be true once we reach the

,----
| else if (has_static)
`----

in line 1750, because we break out earlier if is_class is false in line
1598 of vim9class.c. And once 'has_static = TRUE', we must be in a
class and there fore is_class is true.

Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-11-21 19:57:05 +01:00
Christian Brabandt
a5218a7330
patch 9.0.2118: [security]: avoid double-free in get_style_font_variants
Problem:  [security]: avoid double-free
Solution: Only fee plain_font, when it is not the same as bold_font

When plain_font == bold_font and bold_font is not NULL, we may end up
trying to free bold_font again, which already has been freed a few lines
above.

So only free bold_font, when the condition gui.font_can_bold is true,
which means that bold_font is not pointing to plain_font (so it needs to
be freed separately).

Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-11-21 19:54:12 +01:00
Christian Brabandt
567cae2630
patch 9.0.2117: [security] use-after-free in qf_free_items
Problem:  [security] use-after-free in qf_free_items
Solution: only access qfpnext, if it hasn't been freed

Coverity discovered a possible use-after-free in qf_free_items. When
freeing the qfline items, we may access freed memory, when qfp ==
qfpnext.

So only access qfpnext, when it hasn't been freed.

Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-11-21 19:52:12 +01:00
Luuk van Baal
e670d17342
patch 9.0.2116: No test for defining sign without attribute
Problem:  No test for defining sign without attribute
Solution: Add test for defining sign without attributes

closes: #13544

Signed-off-by: Luuk van Baal <luukvbaal@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-11-19 10:57:02 +01:00
Christian Brabandt
6701abfb52
patch 9.0.2115: crash when callback function aborts because of recursiveness
Problem:  crash when callback function aborts because of recursiveness
Solution: correctly initialize rettv

Initialize rettv in invoke_popup_callback()

Since v9.0.2030, call_callback may exit early when the callback recurses
too much.  This meant that call_func, which would set rettv->v_type =
VAR_UNKNOWN, was not being called.

Without rettv->v_type being explicitly set, it still contained whatever
garbage was used to initialize the stack value in invoke_popup_callback.
This would lead to possible crashes when calling clear_tv(&rettv).

Rather than rely on action at a distance, explicitly initialize rettv's
type to VAR_UNKNOWN so clear_tv can tell nothing needs to be done.

closes: #13495
closes: #13545
Signed-off-by: James McCoy <jamessan@jamessan.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-11-19 10:52:50 +01:00
Christian Brabandt
22cbc8a4e1
patch 9.0.2114: overflow detection not accurate when adding digits
Problem:  overflow detection not accurate when adding digits
Solution: Use a helper function

Use a helper function to better detect overflows before adding integer
digits to a long or an integer variable respectively. Signal the
overflow to the caller function.

closes: #13539

Signed-off-by: Christian Brabandt <cb@256bit.org>
Signed-off-by: Michael Henry <vim@drmikehenry.com>
Signed-off-by: Ernie Rael <errael@raelity.com>
2023-11-19 10:47:21 +01:00
Christian Brabandt
22a97fc241
patch 9.0.2113: Coverity warns for another overflow in shift_line()
Problem:  Coverity warns for another overflow in shift_line()
Solution: Test for INT_MAX after the if condition, cast integer values
          to (long long) before multiplying.

Signed-off-by: Christian Brabandt <cb@256bit.org>
Signed-off-by: Michael Henry <vim@drmikehenry.com>
Signed-off-by: Ernie Rael <errael@raelity.com>
2023-11-19 10:45:24 +01:00
Ivan Pešić
cc6be3e755
translation(sr): Update Serbian messages translation (#13538)
Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-11-17 12:54:10 +01:00
Christian Brabandt
6bf131888a
patch 9.0.2112: [security]: overflow in shift_line
Problem:  [security]: overflow in shift_line
Solution: allow a max indent of INT_MAX

[security]: overflow in shift_line

When shifting lines in operator pending mode and using a very large
value, we may overflow the size of integer. Fix this by using a long
variable, testing if the result would be larger than INT_MAX and if so,
indent by INT_MAX value.

Special case: We cannot use long here, since on 32bit architectures (or
on Windows?), it typically cannot take larger values than a plain int,
so we have to use long long count, decide whether the resulting
multiplication of the shiftwidth value * amount is larger than INT_MAX
and if so, we will store INT_MAX as possible larges value in the long
long count variable.

Then we can safely cast it back to int when calling the functions to set
the indent (set_indent() or change_indent()). So this should be safe.

Add a test that when using a huge value in operator pending mode for
shifting, we will shift by INT_MAX

closes: #13535

Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-11-16 22:04:38 +01:00
Christian Brabandt
73b2d3790c
patch 9.0.2111: [security]: overflow in get_number
Problem:  [security]: overflow in get_number
Solution: Return 0 when the count gets too large

[security]: overflow in get_number

When using the z= command, we may overflow the count with values larger
than MAX_INT. So verify that we do not overflow and in case when an
overflow is detected, simply return 0

Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-11-16 22:04:38 +01:00
Christian Brabandt
060623e4a3
patch 9.0.2110: [security]: overflow in ex address parsing
Problem:  [security]: overflow in ex address parsing
Solution: Verify that lnum is positive, before substracting from
          LONG_MAX

[security]: overflow in ex address parsing

When parsing relative ex addresses one may unintentionally cause an
overflow (because LONG_MAX - lnum will overflow for negative addresses).

So verify that lnum is actually positive before doing the overflow
check.

Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-11-16 22:04:38 +01:00
Christian Brabandt
58f9befca1
patch 9.0.2109: [security]: overflow in nv_z_get_count
Problem:  [security]: overflow in nv_z_get_count
Solution: break out, if count is too large

When getting the count for a normal z command, it may overflow for large
counts given. So verify, that we can safely store the result in a long.

Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-11-16 22:04:37 +01:00
Christian Brabandt
ac63787734
patch 9.0.2108: [security]: overflow with count for :s command
Problem:  [security]: overflow with count for :s command
Solution: Abort the :s command if the count is too large

If the count after the :s command is larger than what fits into a
(signed) long variable, abort with e_value_too_large.

Adds a test with INT_MAX as count and verify it correctly fails.

It seems the return value on Windows using mingw compiler wraps around,
so the initial test using :s/./b/9999999999999999999999999990 doesn't
fail there, since the count is wrapping around several times and finally
is no longer larger than 2147483647. So let's just use 2147483647 in the
test, which hopefully will always cause a failure

Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-11-16 22:04:37 +01:00
Christian Brabandt
cb0b99f067
patch 9.0.2107: [security]: FPE in adjust_plines_for_skipcol
Problem:  [security]: FPE in adjust_plines_for_skipcol
Solution: don't divide by zero, return zero

Prevent a floating point exception when calculating w_skipcol (which can
happen with a small window when the number option is set and cpo+=n).

Add a test to verify

Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-11-16 22:04:37 +01:00
Christian Brabandt
25aabc2b8e
patch 9.0.2106: [security]: Use-after-free in win_close()
Problem:  [security]: Use-after-free in win_close()
Solution: Check window is valid, before accessing it

If the current window structure is no longer valid (because a previous
autocommand has already freed this window), fail and return before
attempting to set win->w_closing variable.

Add a test to trigger ASAN in CI

Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-11-16 22:04:00 +01:00
Luuk van Baal
bb800a7907
patch 9.0.2105: skipcol not reset when topline changed
Problem:  Skipcol is not reset when topline changed scrolling cursor to top
Solution: reset skipcol

closes: #13528
closes: #13532

Signed-off-by: Luuk van Baal <luukvbaal@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-11-14 17:05:18 +01:00
rhysd
bc8f79d36a
patch 9.0.2104: wast filetype should be replaced by wat filetype
Problem:  wast filetype should be replaced by wat filetype
Solution: start using the official wat filetype name

runtime: rename `wast` filetype to `wat` (Wasm text format)

The problem is the name of the current filetype wast. When the plugin
was initially created, the file extension for Wasm text format was not
fixed and .wast was more popular.

However, recently .wat became the official file extension for
WebAssembly text (WAT) format and .wast is now a file extension for the
unofficial WAST format, which is a superset of .wat for the convenience
to describe the Wasm specification conformance tests.

https://webassembly.js.org/docs/contrib-wat-vs-wast.html

However for now, let's keep using the `wat` filetype even for the .wast
extension, so that we at least do not lose the filetype settings and
syntax highlighting. This can be adjusted later, if it turns out to have
a separate need for.

closes: #13533

Signed-off-by: rhysd <lin90162@yahoo.co.jp>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-11-14 16:46:07 +01:00
Christian Brabandt
2076463e38
patch 9.0.2103: recursive callback may cause issues on some archs
Problem:  recursive callback may cause issues on some archs
Solution: Decrease the limit drastically to 20

Recursive callback limit causes problems on some architectures

Since commit 47510f3d6598a1218958c03ed11337a43b73f48d we have a test
that causes a recursive popup callback function to be executed. However
it seems the current limit of 'maxfuncdepth' option value is still too
recursive for some 32bit architectures (e.g. 32bit ARM).

So instead of allowing a default limit of 100 (default value for
'maxfuncdepth'), let's reduce this limit to 20. I don't think there is a
use case where one would need such a high recursive callback limit and a
limit of 20 seems reasonable (although it is currently hard-coded).

closes: #13495
closes: #13502

Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-11-12 16:59:29 +01:00
Christian Brabandt
9588666360
patch 9.0.2102: matchparen highlight not cleared in completion mode
Problem:  matchparen highlight not cleared in completion mode
Solution: Clear matchparen highlighting in completion mode

Remove hard-coded hack in insexpand.c to clear the :3match before
displaying the completion menu.

Add a test for matchparen highlighting. While at it, move all test tests
related to the matchparen plugin into a separate test file.

closes: #13493
closes: #13524

Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-11-12 16:55:01 +01:00
Shane-XB-Qian
2dd613f57b
runtime(termdebug): improve the breakpoint sign label (#13525)
// related #12589
// that should be the last chat (I) with Bram, r.i.p

Signed-off-by: shane.xb.qian <shane.qian@foxmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-11-12 16:53:39 +01:00
shane.xb.qian
fdbadea4b6
patch 9.0.2101: CI: test_termdebug may still fail
Problem:  CI: test_termdebug may still fail
Solution: use term_wait() to make it more robust

closes: #13529

Signed-off-by: shane.xb.qian <shane.qian@foxmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-11-12 09:42:12 +01:00
Christian Brabandt
305127f9f2
patch 9.0.2100: CI: test_termdebug fails
Problem:  CI: test_termdebug fails
Solution: only test for a changed winlayout, if the window
          width actually changed

Also, include an unrelated comment (which doesn't warrant its own patch
number)

Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-11-11 18:59:33 +01:00
Nir Lichtman
6cd2d1df92
patch 9.0.2099: win32: terminal codes clear the terminal
Problem:  Terminal control codes¹ are sent even when silent
          mode is on, causing the terminal to clear up
Solution: Block any terminal codes when silent mode is on

¹https://learn.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences

fixes: #12822
closes: #13521

Signed-off-by: Nir Lichtman <nir@lichtman.org>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-11-11 11:33:43 +01:00
ObserverOfTime
4f9074b96c
patch 9.0.2098: No filetype support for xcompose files
Problem:  No filetype support for xcompose files
Solution: Add filetype detection

closes: #13508

Signed-off-by: ObserverOfTime <chronobserver@disroot.org>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-11-11 09:12:27 +01:00
Gerrit Meier
8f0fe20ff1
patch 9.0.2097: No support for cypher files
Problem:  No support for cypher files
Solution: Add cypher filetype detection

Cypher query language support to work with (mostly) graph databases.

Already existing lsp support in Neovim's nvim-lspconfig:
https://github.com/neovim/nvim-lspconfig/blob/master/doc/server_configurations.md#cypher_ls

closes: #13516

Signed-off-by: Gerrit Meier <meistermeier@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-11-11 08:58:26 +01:00
Ernie Rael
03042a2753
patch 9.0.2096: Vim9: confusing usage of private
Problem:  Vim9: confusing usage of private
Solution: clarify and use protected keyword instead

[vim9class] document `_` as protected instead of private

fixes #13504
closes: #13520

Signed-off-by: Ernie Rael <errael@raelity.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-11-11 08:53:32 +01:00
shane.xb.qian
ca48202b6f
runtime(termdebug): improve window handling, shorten var types
closes #13474

Signed-off-by: shane.xb.qian <shane.qian@foxmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-11-08 22:03:26 +01:00
shane.xb.qian
7fbbd7fdc6
runtime(termdebug): handle buffer-local mappings properly
closes: #13475

Signed-off-by: shane.xb.qian <shane.qian@foxmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-11-08 21:46:30 +01:00
Christian Brabandt
6a650bf696
patch 9.0.2095: statusline may look different than expected
Problem:  statusline may look different than expected
Solution: do not check for highlighting of stl and stlnc characters

statusline fillchar may be different than expected

If the highlighting group for the statusline for the current window
|hl-StatusLine| or the non-current window |hl-StatusLineNC| are cleared
(or do not differ from each other), than Vim will use the hard-coded
fallback values '^' (for the non-current windows) or '=' (for the
current window).  I believe this was done, to make sure the statusline
will always be visible and be distinguishable from the rest of the
window.

However, this may be unexpected, if a user explicitly defined those
fillchar characters just to notice that those values are then not used
by Vim.

So, let's assume users know what they are doing and just always return
the configured stl and stlnc values.  And if they want the statusline to
be non-distinguishable from the rest of the window space, so be it.  It
is their responsibility and Vim shall not know better what to use.

fixes: #13366
closes: #13488

Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-11-08 21:23:29 +01:00
Yegappan Lakshmanan
1fc47c2c9b
patch 9.0.2094: Vim9: need more assignment tests
Problem:  Vim9: need more assignment tests
Solution: Add test for using different types in assignment, function
          arguments and return values

closes: #13491

Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-11-08 21:10:11 +01:00
zeertzjq
4d62a2f443
patch 9.0.2093: Unsupported option causes skipping of modeline test
Problem:  Unsupported option causes rest of modeline test to be skipped.
Solution: Revert the change from patch 8.2.1432.

closes: #13499
closes: #13500

Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-11-08 20:51:02 +01:00
Christian Brabandt
2a94e98792
patch 9.0.2092: tests: failure in test_arabic
Problem:  tests: failure in test_arabic
Solution: adjust the test for the changed arabic keymap

Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-11-05 19:18:52 +01:00
Restorer
3570631dc6
translation(ru): Update the translation of Russian messages to Vim 9.0.2091 (#13490)
Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-11-05 17:56:14 +01:00
Yegappan Lakshmanan
6709816f78
patch 9.0.2091: Vim9: cannot convert list to string using +=
Problem:  Vim9: cannot convert list to string using +=
          (after 9.0.2072)
Solution: convert dict index to string later in compile_member()

fixes: #13485
closes: #13486

Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-11-05 10:07:03 +01:00
Christian Brabandt
57f9ce1a09
patch 9.0.2090: complete_info() skips entries with 'noselect'
Problem:  complete_info() skips entries with 'noselect'
Solution: Check, if first entry is at original text state

Unfortunately, Commit daef8c74375141974d61b85199b383017644978c
introduced a regression, that when ':set completeopt+=noselect' is set
and no completion item has been selected yet, it did not fill the
complete_info['items'] list.

This happened, because the current match item did not have the
CP_ORIGINAL_TEXT flag set and then the cp->prev pointer did point to the
original flag item, which caused the following while loop to not being
run but being skipped instead.

So when the 'noselect' is set, only start with to the previous selection
item, if the initial completion item has the CP_ORIGINAL_TEXT flag set,
else use the 2nd previous item instead.

fixes: #13451
closes: #13452

Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-11-04 09:58:14 +01:00
GuyBrush
15d270019e
patch 9.0.2089: sound_playfile() fails when using powershell
Problem:  sound_playfile() fails when using powershell
Solution: quote filename using doublequotes, don't escape filename,
          because it doesn't use the shell

Avoiding powershell escaping because mci open command doesn't support
single quoted filenames: open 'C:\whatever\sound.wav' is not valid.

closes: #13471

Signed-off-by: GuyBrush <miguel.barro@live.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-11-04 09:54:00 +01:00
Yegappan Lakshmanan
5a53925a6e
patch 9.0.2088: Vim9: still allows abstract static methods
Problem:  Vim9: still allows abstract static methods
          (after v9.0.2084, v9.0.2085 and v9.0.2087)
Solution: Disallow abstract static methods

closes: #13479

Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-11-04 09:42:46 +01:00
Christian Brabandt
33c1da7ff4
patch 9.0.2087: build-failure in vim9class
Problem:  build-failure in vim9class
Solution: reference correct error message,
          disable non-failing test

closes: #13476
closes: #13477

Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-11-02 22:45:12 +01:00
zeertzjq
deba02ddd4
patch 9.0.2086: code cleanup for option callbacks needed
Problem:  code cleanup for option callbacks needed
Solution: remove flag os_doskip, it's not necessary, as we can check,
          whether an error message was returned

Remove unnecessary field os_doskip

Callback functions for boolean options set os_doskip immediately before
returning an error message, so os_doskip isn't actually needed.

closes: #13461

Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-11-02 21:01:19 +01:00
Yegappan Lakshmanan
2b358adde0
patch 9.0.2085: Vim9: abstract can be used in interface
Problem:  Vim9: abstract can be used in interface
Solution: Disallow the use of abstract in an interface

fixes: #13456
closes: #13464

Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-11-02 20:58:58 +01:00
Yegappan Lakshmanan
ef9e3f8924
patch 9.0.2084: Vim9: abstract static methods are possible
Problem:  Vim9: abstract static methods are possible
Solution: Disallow abstract static methods

fixes: #13462
closes: #13466

Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-11-02 20:43:57 +01:00
Zdenek Dohnal
1b1c9f272d
patch 9.0.2083: Perl: xsubpp may be in non-standard location
Problem:  Perl: xsubpp may be in non-standard location
Solution: Add --with-subpp configure option

configure.ac: Add --with-xsubpp configure option

Some environments (such as flatpaks) cannot count on xsubpp being
in the common Perl directory, so a configure option should be used for
clean solution.

closes: #13470

Signed-off-by: Zdenek Dohnal <zdohnal@redhat.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-11-02 20:19:06 +01:00
James McCoy
43cb8e1c3b
patch 9.0.2082: test_channel may fail because of IPv6 config issue
Problem:  test_channel may fail because of IPv6 config issues
Solution: Catch and skip the test, if getaddrinfo() fails with
          'Address family not supported'

Mark tests as skipped when ch_open encounters E901

On some of the Debian build systems, the IPv6 channel tests fail because
`ch_open('[::1]:<port>', ...)` raises the error "E901: getaddrinfo() in
channel_open(): Address family for hostname not supported".

This appears to happen because getaddrinfo() can't perform the reverse
lookup for the ::1, which is a config issue on that system.  Therefore,
instead of reporting a test failure, mark the test as skipped due to the
bad network config

closes: #13473

Signed-off-by: James McCoy <jamessan@jamessan.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-11-02 20:05:38 +01:00
Luuk van Baal
1bf1bf569b
patch 9.0.2081: smoothscroll may result in wrong cursor position
Problem:  With 'smoothscroll' set, "w_skipcol" is not reset when unsetting 'wrap'.
          Resulting in incorrect calculation of the cursor position.
Solution: Reset "w_skipcol" when unsetting 'wrap'.

fixes:  #12970
closes: #13439

Signed-off-by: Luuk van Baal <luukvbaal@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-10-28 21:43:31 +02:00
Yegappan Lakshmanan
171c50e0b0
patch 9.0.2080: vim9_script test too large
Problem:  vim9_script test too large
Solution: split vim9 type alias test into
          separate test file

Move type alias tests to a separate test file

closes: #13447

Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-10-28 21:31:53 +02:00
Doug Kearns
c1c177a47b
patch 9.0.2079: Not all Dart files detected
Problem:  Not all Dart files detected
Solution: Add shebang filetype detection for Dart

closes: #13449

Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-10-28 21:21:49 +02:00
Yegappan Lakshmanan
feaccd2395
patch 9.0.2078: several problems with type aliases
Problem:  several problems with type aliases
Solution: Check for more error conditions, add tests,
          fix issues

Check for more error conditions and add additional tests

fixes  #13434
fixes  #13437
fixes  #13438
closes #13441

Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-10-28 15:53:55 +02:00
Christian Brabandt
87ca5e86fa
patch 9.0.2077: CI fails because of trailing whitespace in test
Problem:  CI fails because of trailing whitespace in test
Solution: Remove it

Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-10-27 19:48:38 +02:00