| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
Now it shows something like `5 lines yanked into "~my.extreg`
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implements "extended registers"
Extended registers provide access to a separate namespace of registers
backed by custom lua callback functions.
A new special register ("~) is introduced, which prompts the user for
the name of an extregistr to yank or paste from.
This enables file-backed or cloud-synced or other arbitrary register
behavior.
One can now use:
`"~file_extreg<cr>yy`
to yank into the "file_extreg" register.
AI-assisted: Qwen3-Coder
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
vim-patch:9.2.1175: setreg() block width wrong for unprintable chars
When yanking, the width of a <c-v>{motion}y register
is determined by the virtual colums of the text. However
in setreg() in 'b' mode use an idosyncratic width measurement
where C0 control chars (ASCII 0x00 - 0x19) and invalid UTF-8 bytes
have width 1 instead of their display width (2 or 4 cells).
Consider the following test case:
let strings = ['"reference', '"Übel', "\"aa\x07bb", "\"qq\x82", "\"x\nbabbel"]
for string in strings
call append('$', string)
exec "normal G0\<c-v>$\"ay"
let one = getregtype('a')
if string != strings[-1]
call setreg("b", string, 'b')
let two = getregtype('b')
else
let two = "na"
endif
call setreg("c", [string], 'b')
let three = getregtype('c')
call append('$', '"yank: '.one.", string: ".two.", list: ".three)
endfor
AFter this fix, all the three ways of measuring the width gives
equal values (or two, in the case of not being able to use setreg()
with a plain string in the first case)
|
| |
|
|
|
|
|
|
| |
part of a series, next big one is gonna be bring utf_ptr2schar and
friends into the New world. after that it might be worth brushing of
some benchmarks and re-microoptimize the hottest loops.
also some const-y constess but it is fine.
|
| |
|
|
|
|
|
| |
yes NVIM_TEST_TRACE_LEVEL does exist but simply displaying the
stacktrace of the error should not be opt in. Now that we "own" the
harness we can borrow some harness code for the child to only print spec
file lines and not testutil lines.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: Option validators and setters repeatedly pass error buffers and
their sizes separately. Some setters return messages in static storage.
Solution:
- Add CharBuf for borrowed writable storage, with its length including
space for a terminating NUL.
- Move option error buffers to the callers that report errors. Preserve
existing buffer sizes, truncation, and calls that do not need a
message.
- Consolidate option error formatting and the duplicated code that lists
valid option values.
- Return error messages directly from do_one_set_option().
- Remove unused arguments from get_option_newval() and
set_option_value_for().
- Handle legacy TTY assignments in the existing callers and remove the
redundant compatibility wrapper.
- Reuse CharBuf for Tree-sitter query errors.
- Pass CharBuf through the statusline and statuscolumn builders,
retaining the buffer sizes provided by their callers, including title
formatting.
AI-assisted
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
strdisplaywidth('ทำ') is 1, but that cluster needs two cells. A SpacingMark has
positive advance width (Unicode core spec D55), so it cannot share its base's
cell: no Thai font fits a consonant plus SARA AM (U+0E33) in one cell, the
narrowest needing 119% of one and most 180-210%, measured against a 0.600 em
cell. UAX#29 GB9a keeps the mark in its base's cluster, which is correct for
segmentation and says nothing about width.
setcellwidths() cannot work around it, because the collapse is per cluster, not
per codepoint.
Vim reports 2 here. Devanagari and Bengali matras and Khmer and Tamil vowel
signs are the same case.
Solution:
Add a cell for each remaining codepoint in the cluster whose boundclass is
UTF8PROC_BOUNDCLASS_SPACINGMARK, clamped to the maximum cells per cluster.
Segmentation is untouched, so the cursor and selection still treat the cluster
as one unit.
U+FF9E and U+FF9F, the halfwidth katakana sound marks, are Grapheme_Extend
rather than SpacingMark, so they are matched separately. This is not a general
solution for grapheme extenders that carry width -- that needs a queryable
table -- but it does fix the reported regressions for Thai and Japanese
(refs #34733).
AI-assisted
fixes #34733
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: auto-hiding item groups (minwid==0) are hidden unless they
contain a non-empty normal item or no items at all. In general, normal
items are those that show information: strings, numbers, flags.
Expression items %{...} are also treated as normal, see for example
the terminal exit code in the flags section.
But in contrast, when using re-evaluated expression items %{%...%},
the item group looks for normal items in the expression result.
This is useful for dynamically deciding which items should be in use.
Example: stl=%f%(\ %h%w%{%&buftype==''?'%m%r':''%}%).
But when the result only contains non-normal items like highlights, the
non-emptiness of the result doesn't ensure the item group to be shown.
Example: the diagnostics section uses %{%...%} to add highlighting,
and thus cannot use auto-hiding and has to resort to a non-idiomatic and
verbose solution to add padding between itself and the next section.
Solution: look for normal items (empty or not) in the expression result.
If there are none, treat the whole result as one normal item.
BREAKING CHANGE: it is no longer easily possible to use %{%...%} to add
dynamic content with non-normal items (e.g. highlighting) to an item
group with minwid==0 without influencing auto-hiding.
Workaround: add a dummy empty normal item like %{''} to the result.
Or refactor so that the whole item group is created inside %{%...%}.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Now this was a cargo cult anti-pattern to write home about.
Doing painful save-and-restore bookkeeping around a separate
`magic_overruled` decoy global is just as messy as doing painful
save-and-restore logic around `p_magic` itself. only that now you need
to wrap every access to the effective value in a function call.
This replaces this with a marvellous new Clean Code technique™:
passing in the intended behavior as a function parameter to functions
where either the option or an explicit value might be used.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
Redudant code
Solution:
Add `path_fold_char()` to normalize path sep.
Refactor `pathcmp()` and `path_fnamencmp()` into `path_cmp`.
| feature | pathcmp | path_fnamencmp | path_cmp(now) |
| ------------------------ | -------------- | -------------- | ------------- |
| case folding | `mb_toupper()` | `utf_fold()` | `utf_fold()` |
| consults fileignorecase | ✅ | ✅ | `ic` param |
| `maxlen` | ✅ | ✅ | ✅ |
| `/` == `\` | ✅ | ✅ | ✅ |
| MSWIN drive letter | ❌ | ✅ | ✅ |
| sep affects sorting | ✅ | ❌ | ✅ |
| ignores a trailing slash | ✅ | ❌ | ✅ |
Refactor `path_fnamecmp` and `path_full_compare` into `path_equal`,
with flags controlling "no filesystem" comparison (i.e. `path_cmp`), env
variables expansion, absolute path resolution and filesystem access.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
The magic globals `it`, `describe`, etc., are more trouble than they are
worth.
- Hooking into `after_each` requires `getfenv()` hacks.
- They confuse luals/emmylua, because the top-level `.luarc.json` isn't
merged with `test/.luarc.json` (apparently a luals limitation?)
- They totally defeat discoverability because the user just has to
"know" about the various magic symbols.
So they harm DX, which means they serve no purpose at all.
Solution:
- Expose the test API from `testutil`, so tests can call `t.it()`,
`t.describe()`, etc., in the conventional way.
- Drop `getfenv()` hacks.
- Drop the `setfenv()` injection in `load_chunk`.
- Drop `test/_meta.lua`.
|
| |
|
|
|
|
|
|
| |
Problem: when PR #40621 removed a 50 cell restriction to item group
minwid, a possible integer overflow was introduced when the added
padding is multiplied with the number of fillchar bytes.
Solution: when there is not enough buffer capacity left, reduce the
number of added fillchars before calculating the number of added bytes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: Separation markers (%=) are ignored within item groups. This
lead to a regression when the C implementation of the statusline was
replaced with a default expression. When the user configured a custom
ruler expression with a %= and used the overloaded item group syntax to
set the ruler width, the separation marker worked in the ruler, but not
when the ruler was incorporated into the statusline where the item group
syntax was interpreted in the usual way.
Solution: Analogously to top-level behaviour, expand separation markers
evenly within item groups until `minwid` is reached (if set).
ref https://github.com/neovim/neovim/pull/33036
fix https://github.com/neovim/neovim/issues/39984
ref https://github.com/neovim/neovim/issues/40247
Problem: The recursion offset into the static `stl_items` was not taken
into account when adjusting the item count after truncation.
Steps to reproduce: first prepare `stl_items`:
set stl=%{%repeat('%#Error#',10)%}
then watch how the Error highlight leaks into the recursive call:
set stl=%l%l%l%{%nvim_eval_statusline('test%l%<',{'maxwidth':3,'highlights':1}).highlights%}
ref https://github.com/neovim/neovim/issues/32259
* fix(statusline): consistent truncation at multicell character
Problem 1: truncation of item groups at multicell character didn't take
into account that minwid can be specified as a negative number.
Problem 2: after truncation at top-level from the right at multicell
character, the returned width was always `maxwidth`, even though the
actual width was reduced. In vim, this can be observed as a statusline
that is not fully drawn until the edge of the screen:
vim --clean +"set ls=2 stl=%{%repeat('x',&columns-2)%}🙂x%<"
Problem 3: after truncation at top-level from the left at multicell
character, the resulting gap to reach `maxwidth` again was filled with
fillchars, but then the final NUL was not set correctly.
This can be seen in the following example, where the statuscolumn spills
into the editing area starting from line 10:
nvim --clean +"set number stc=%<x🙂%{repeat('x',43)}%l" +"norm yy10p"
Solution: fix the small errors and, at top-level, consistently reduce
the size instead of compensating with fillchars. In the case of the
statusline and the winbar, the remaining place is filled with the
configured fillchars in `win_redr_custom`, after `build_stl_str_hl` has
returned. In all other cases (title, icon, statuscol, tabline, ruler),
there seems to be no point in adding additional spaces at the end.
* feat(statusline)!: scope %< to item groups
Problem:
Previously, item groups were only truncated at the beginning, which is
often not desired. In the example
%.15(path: %f%)
the group's title/label is truncated away:
<th/to/file.txt
Truncation markers (%<) in item groups were processed at the top-level
in the end, which can be confusing. Only the first %< is used for the
whole string, and it is used even if the containing item group is
hidden. Additionally, in the case of hidden item groups, the marker's
position was not adapted. For example,
%(hidden%<%)%f
had the effect of truncating the path somewhere in the middle:
/path/<file.txt
Solution:
Make truncation consistent with top-level behaviour, which has a better
default of truncating at the first `Normal` item, i.e.
path: <file.txt
and allows for fine-grained control with truncation markers (%<). E.g.
%.15(path: %f%<%)
now yields
path: /path/to>
The original behaviour can be restored like so:
%.15(%<path: %f%)
BREAKING CHANGE: %< is no longer processed at top-level
- the default truncation behaviour has changed: now at first item
- truncation markers inside item groups don't affect truncation outside
of the item group anymore
- several truncation markers can now have an effect when separated with
item groups, whereas previously only the first one globally had
ref https://github.com/neovim/neovim/issues/39984
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
Various out-of-bounds writes inherited from vim (examples assume MAXPATHL==4096):
- truncated item groups where minwid>maxwid:
nvim --clean +"set stl=%<%{%repeat('x',4096-11)%}%50.5(12🙂345%)"
leads to fillchars spilling over the end of the group/buffer while trying to
compensate for truncating at a multicell character because minwid<=maxwid is assumed
- left-aligned item groups with multi-byte fillchar:
nvim --clean +"set fillchars+=stl:∙ stl=%<%{%repeat('x',4096-3)%}%-2(X%)"
wrongly leads to padding at the end of the statusline and `out_p-out==4097`
because the bounds check assumes a 1-byte fillchar
- right-aligned item groups with 1-byte fillchar:
nvim --clean +"set stl=%<%{%repeat('x',4096-4)%}%4(XY%)"
leads to "YX" instead of "XY" at the end of the statusline
because `memmove` is done before adjusting the offset
- right-aligned item groups with multi-byte fillchar:
nvim --clean +"set fillchars+=stl:∙ stl=%5(X%)"
leads to "∙∙∙∙<e2>", i.e. the fillchar is being written over the group contents
and eventually being overwritten itself at the second byte with the final NUL,
because the padding counter assumes a 1-byte fillchar; to crash Neovim,
nvim --clean +"set fillchars+=stl:∙ stl=%<%{%repeat('x',4096-149)%}%50(X%)"
Solution:
Clearer variable names and no recycling of variables for different purposes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Debian's ppc64el build, the unittests are failing during preprocess
with
test/unit/testutil.lua:298: declaration specifier expected near '__typeof' at line 298
test/unit/testutil.lua:282: assertion failed!
Running with NVIM_TEST_PRINT_I set shows these lines as being the
problem when trying to preprocess test/unit/fixtures/posix.h.
690 extern __typeof (strtold) strtold ;
691 extern __typeof (strtold_l) strtold_l ;
692 extern __typeof (strfroml) strfroml ;
693 extern __typeof (qecvt) qecvt ;
694 extern __typeof (qfcvt) qfcvt ;
695 extern __typeof (qgcvt) qgcvt ;
696 extern __typeof (qecvt_r) qecvt_r ;
697 extern __typeof (qfcvt_r) qfcvt_r ;
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
On "arm clang unittest" CI job, `make unittest` sometimes fails with
lots of these messages:
FAILED test/unit/testutil.lua @ 773: ...
test/unit/testutil.lua:773:
test/unit/testutil.lua:297: declaration specifier expected near '_Static_assert' at line 429
exit code: 256
stack traceback:
test/unit/testutil.lua:773: in function 'itp_parent'
test/unit/testutil.lua:811: in function <test/unit/testutil.lua:801>
Solution:
Update filter_complex_blocks.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
Many color schemes assume the Comment hl group is dim text and use it
for secondary text, decorations, or parts of UI. This is true for many
color schemes but not all.
Solution:
Introducing a new highlight group with a more specific meaning, similar
to Underlined or Ignore.
The new group links to Comment by default so the behavior is unchanged
for color schemes that don't define it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
The Lua test harness still ran through standalone -ll mode, so tests
depended on the low-level Lua path instead of the regular Nvim Lua
environment. That also meant os.exit() coverage had to carry an ASAN
workaround because Lua's raw process exit skipped Nvim teardown and let
LeakSanitizer interfere with the observed exit code.
Solution:
Run the harness and related fixtures with nvim -l. Patch os.exit() in
the main Lua state to exit through getout(), so scripts observe normal
Nvim shutdown while standalone -ll remains available for generator-style
scripts. As a consequence, the startup test can assert os.exit() without
disabling leak detection.
AI-assisted: Codex
|
| |
|
|
|
|
| |
Co-authored-by: michael-grunder <michael.grunder@gmail.com>
Co-authored-by: Olivia Kinnear <git@superatomic.dev>
Co-authored-by: Felipe Matarazzo <felipemps@protonmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(#39517)
Problem: With $d='[dir]', `:e $d/file.txt` opens the wrong file,
`:e $d/<Tab>` fails to complete, and `glob('$d/*')` returns
nothing. Wildcard characters inside expanded environment
variables get picked up by globbing again.
Solution: Turn the 4th parameter of expand_env_esc() from a bool into a
string of characters to escape in each expanded value. Callers
that pass the result to wildcard expansion should include
PATH_ESC_WILDCARDS in addition to " \t" (glepnir).
closes: vim/vim#20053
https://github.com/vim/vim/commit/20e98ff1cc3ffc13d42579d2bf9b9567f98595a2
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Replace the busted-based Lua test runner with a repo-local harness.
The new harness runs spec files directly under `nvim -ll`, ships its own
reporter and lightweight `luassert` shim, and keeps the helper/preload
flow used by the functional and unit test suites.
Keep the file boundary model shallow and busted-like by restoring `_G`,
`package.loaded`, `package.preload`, `arg`, and the process environment
between files, without carrying extra reset APIs or custom assertion
machinery.
Update the build and test entrypoints to use the new runner, add
black-box coverage for the harness itself, and drop the bundled
busted/luacheck dependency path.
AI-assisted: Codex
|
| |
|
|
| |
AI-assisted: Codex
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
libmpack encodes boundary values -129 and -32769 with wrong integer
sizes:
- -129 as int8 instead of int16
- -32769 as int16 instead of int32
because the boundary checks compare against the wrong values (e.g., lo
< 0xffffff7f instead of lo < 0xffffff80). This caused data corruption:
-129 would decode as 127.
Solution:
Fix off-by-one errors in the two's complement boundary constants:
0xffffff80 (-128, min int8) and 0xffff8000 (-32768, min int16).
Fixes #37202
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
Applications running inside :terminal that use DEC private mode 2026
(synchronized output) to batch screen updates get garbled rendering.
Neovim's embedded libvterm does not handle mode 2026, so the
synchronization sequences are ignored and intermediate screen states
leak through as visual corruption.
Solution:
Add mode 2026 support to libvterm's state machine and wire it through
to terminal.c. When an application enables mode 2026, invalidation of
the terminal buffer is deferred until the application disables it,
causing all accumulated screen updates to flush as a single
atomic refresh.
* fix(terminal): harden sync output redraw gating
Problem:
The initial mode 2026 implementation gated invalidate_terminal()
but missed three other redraw paths: term_sb_push/term_sb_pop
bypassed the gate by directly adding to invalidated_terminals,
refresh_timer_cb could fire mid-sync flushing partial state, and
the 10ms timer delay after sync-end left a window for stale
repaints.
Solution:
- Gate term_sb_push/term_sb_pop during synchronized output
- Skip syncing terminals in refresh_timer_cb
- On sync end, schedule a zero-delay full-screen refresh via
sync_flush_pending flag in terminal_receive()
- Add news.txt entry for mode 2026 support
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* test(terminal): add vterm unit tests for mode 2026
Add unit-level tests for synchronized output (mode 2026) to
vterm_spec.lua, covering settermprop callbacks and DECRQM
query/response.
Suggested-by: justinmk
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* fix(terminal): address review feedback for mode 2026
- Use multiqueue_put(main_loop.events) instead of restarting the
global refresh timer on sync end, to avoid affecting other
invalidated terminals.
- Add screen:expect_unchanged() to verify screen doesn't update
during sync mode.
- Merge buffer-lines test into existing test.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(#38102)
Problem: A stack-buffer-overflow occurs when rendering a statusline
with a multi-byte fill character on a very wide terminal.
The size check in build_stl_str_hl() uses the cell width
rather than the byte length, allowing the subsequent fill
loop to write beyond the 4096-byte MAXPATHL buffer
(ehdgks0627, un3xploitable).
Solution: Update the size check to account for the byte length of
the fill character (using MB_CHAR2LEN).
Github Advisory:
https://github.com/vim/vim/security/advisories/GHSA-gmqx-prf2-8mwf
https://github.com/vim/vim/commit/4e5b9e31cb7484ad156fba995fdce3c9b075b5fd
Co-authored-by: Christian Brabandt <cb@256bit.org>
|
| |
|
|
|
|
| |
Problem:
libvterm doesn't support parsing the dim and overline attributes, so when a program running in the embedded terminal emits one of these escape codes, we ignore it and don't surface it to the outer terminal.
Solution: tweak libvterm to add support for both attributes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
fix #37867
This bug happens when only one end is moved between different nodes,
but the other end is also moved but within the same node.
When this happens we need the correct previous position even for the
internal move. This code shall be refactored to make the intent clearer,
(and avoid some unnecessary processing) but this is a fix for the observable
bug.
Thanks to KevinGoodsell for providing a deterministic
reproduce using fuzzing techniques.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(#37955)
Problem: Wrong shortened buffer name after :cd with duplicate slashes.
Solution: Skip over multiple consecutive path separators (zeertzjq).
related: neovim/neovim#37080
closes: vim/vim#19444
https://github.com/vim/vim/commit/f245e17ac70df43fd7fe650c7227bb16a4615283
N/A patches:
vim-patch:9.0.1859: heap-use-after-free in bt_normal()
vim-patch:9.2.0022: bt_quickfix() is slow
|
| |
|
|
|
|
|
|
| |
Problem:
stack->offset value is used as an array index.
Solution:
Instead of comparing the stack->offset value to the size in bytes of the array,
compare the actual length of the array.
|
| |
|
|
|
|
|
|
|
| |
Problem: Vim9: outdated TODO items, disabled tests that work.
Solution: Remove TODO items, run tests that work now. Check that a dict
item isn't locked.
https://github.com/vim/vim/commit/71b768509250b12696e8cc90e5902029f1b5433d
Co-authored-by: Bram Moolenaar <Bram@vim.org>
|
|
