Problem: Cannot use :unlet for an environment variable.
Solution: Make it work. Use unsetenv() if available.
(Yasuhiro Matsumoto, closesvim/vim#2855)
137374fd65
I have `merge.ff = no` in my Git config to not use fast-forward merges
by default, but when updating the Vim sources it should not cause a
merge commit.
[ci skip]
It fails with `nvim -u NONE -c 'set modified' -c 'confirm q'`.
Introduced in 3dffc842f (vim-patch:8.0.0983), but the Vim patch [1] does not
have this assertion.
NULL gets handled in `dialog_msg` [2].
1: 3f9a1ff141
2: c6d36b97ba/src/nvim/ex_docmd.c (L9704-L9705)
Problem: Nasty autocommand causes using freed memory. (Dominique Pelle)
Solution: Do not force executing autocommands if the value of 'syntax' or
'filetype' did not change.
c3ffc9b8d3
Problem: Weird autocmd may cause arglist to be changed recursively.
Solution: Prevent recursively changing the argument list. (Christian
Brabandt, closesvim/vim#2472)
9e33efd152
tmpdir_get() may be an absolute path, but we invoke glob() with
a relative `initial_path`.
That can lead to this error:
[ ERROR ] test/functional/helpers.lua @ 752: after_each
test/helpers.lua:95: cannot open ./Xtest-tmpdir/nvim8jKCjR: No such file or directory
stack traceback:
test/helpers.lua:95: in function 'glob'
test/helpers.lua:273: in function 'check_cores'
test/functional/helpers.lua:757: in function <test/functional/helpers.lua:752>
Problem: Cursorline highlight not removed in some situation. (Vitaly
Yashin)
Solution: Reset last_cursorline when resetting 'cursorline'. (Christian
Brabandt, closesvim/vim#3481)
8c63e0ec31
The scrolling region is always local to a single grid_scroll event, use
local variables and parameters instead.
The invocation of reset_scroll_region in grid_resize is cargo-culted to use
margin reset under exactly the same circumstances, not sure if it is necessary
though.
The statusline may incorporate b:term_title, so redraw it when that
title changes.
Introduce a new function status_redraw_buf to redraw windows associated
with the current buffer.
When building with -DEXITFREE, the ILOG call would result in a crash
trying to access VV_PROGPATH, which had already been released:
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007f8f761082f1 in __GI_abort () at abort.c:79
#2 0x00007f8f760ffa8a in __assert_fail_base (fmt=0x7f8f76253ec8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
assertion=assertion@entry=0x1c74280 <.str.8> " ,\t\n", file=file@entry=0x1c73fe2 "256]'", line=line@entry=610,
function=function@entry=0x1c742e0 <.str.9+32> "") at assert.c:92
#3 0x00007f8f760ffb02 in __GI___assert_fail (assertion=0x1c74280 <.str.8> " ,\t\n", file=0x1c73fe2 "256]'", line=610,
function=0x1c742e0 <.str.9+32> "") at assert.c:101
#4 0x00000000012d87c1 in vim_getenv (name=0x2f5a460 <get_special_key_name.string+64> "NVIM_LOG_FILE") at ../src/nvim/os/env.c:608
#5 0x00000000012d6538 in expand_env_esc (srcp=0x1c2f4e0 <.str.10+32> "",
dst=0x2f5a460 <get_special_key_name.string+64> "NVIM_LOG_FILE", dstlen=4095, esc=false, one=false, prefix=0x0)
at ../src/nvim/os/env.c:351
#6 0x00000000012d85af in expand_env_esc (srcp=0x625000000100 "\004", dst=0x7ffeed88cf40 "", dstlen=32766, esc=237, one=136,
prefix=0x60200401c8b4 <error: Cannot access memory at address 0x60200401c8b4>) at ../src/nvim/os/env.c:472
#7 0x0000000000eb4274 in do_log_to_file (log_file=0x0, log_level=0, context=0x0, func_name=0x0, line_num=0, eol=false, fmt=0x0)
at ../src/nvim/log.c:254
#8 0x0000000000eb305b in open_log_file () at ../src/nvim/log.c:164
#9 0x0000000000eb2cc6 in logmsg (log_level=<error reading variable: Cannot access memory at address 0x268>,
context=<error reading variable: Cannot access memory at address 0x260>,
func_name=<error reading variable: Cannot access memory at address 0x258>,
line_num=<error reading variable: Cannot access memory at address 0x254>,
eol=<error reading variable: Cannot access memory at address 0x253>,
fmt=<error reading variable: Cannot access memory at address 0x248>) at ../src/nvim/log.c:109
#10 0x00000000013022c7 in mch_free_acl (aclent=0x4f59100) at ../src/nvim/os_unix.c:132
#11 0x0000000000efddac in getout (exitval=0) at ../src/nvim/main.c:681
#12 0x0000000000c1bb3e in ex_quit (eap=0x7ffeed88cd00) at ../src/nvim/ex_docmd.c:6067
#13 0x0000000000bab781 in do_one_cmd (cmdlinep=0x7ffeed88f180, flags=10, cstack=0x7ffeed88f1a0, fgetline=0x0, cookie=0x0)
at ../src/nvim/ex_docmd.c:2228
#14 0x0000000000b8de6d in do_cmdline (cmdline=0x7ffeed891ae2 "quit", fgetline=0x0, cookie=0x0, flags=10)
at ../src/nvim/ex_docmd.c:592
#15 0x0000000000b94036 in do_cmdline_cmd (cmd=0x7ffeed891ae2 "quit") at ../src/nvim/ex_docmd.c:268
#16 0x0000000000efb900 in exe_commands (parmp=0x7ffeed890900) at ../src/nvim/main.c:1699
#17 0x0000000000ee96b2 in main (argc=11, argv=0x7ffeed890fa8) at ../src/nvim/main.c:524
- Since the jemalloc upgrade to 5.1.0, I'm seeing weird behavior such as
infinite loops inside jemalloc routines.
- VimR maintainer reported major performance regression correlated with
jemalloc 5.1.0.
ref https://github.com/neovim/neovim/pull/7808
reverts 765515010f
