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
Problem: printf() does not work with only one argument. (Daniel Hahler)
Solution: Allow using just the format. (Ken Takata, closesvim/vim#2687)
c71807db9c
Problem: Invalid memory access when setting wildchar empty.
Solution: Avoid going over the end of the option value. (Dominique Pelle,
closesvim/vim#1509) Make option test check all number options with
empty value.
a12e40351d
Problem: v:option_old and v:option_new are cleared when using :set in
OptionSet autocmd. (Gary Johnson)
Solution: Don't trigger OptionSet recursively.
3f3fb0b147
Resets the TUI cursor color if:
- current 'guicursor' mode does not specify a highlight group
- cursor highlight group has "inverse" or "reverse" flag
- on Nvim exit
We interpret, "inverse" to mean "default cursor".
Example:
hi Cursor guifg=bg guibg=fg
set termguicolors
set guicursor=n-v-c-sm:block,i-ci-ve:ver25-Cursor,r-cr-o:hor20
* When the cursor shape is block, its color will be "inverse"
* When the cursor shape is I-beam, its color will be `hi Cursor`.
This is useful e.g. to prevent `set listchars=eol:¬` causing your cursor
color to a low contrast color in insert mode because you cursor are
often at EOL in insert mode.
close#8572
Problem: File info message not always suppressed with 'F' in 'shortmess'.
(Asheq Imran)
Solution: Save and restore msg_silent. (Christian Brabandt, closesvim/vim#3221)
2f0f871159
ref #8840
ref #9027
When nroff justifies a line, it fills the line with whitespace to meet
$MANWIDTH. With $MANWIDTH=9999, that of course results in nonsense (and
behaves poorly with 'cursorline' option).
To work around that, instead of trying to hard-justify the lines, just
replace the mega-whitespace with a fixed size of 10 spaces.
Perhaps N/Vim needs a "soft justify" feature?
NB: existing `color default` test was actually enough to trigger the bug,
when ext_newgrid=false is used. I created the `:hi Normal` test as
I thought the builtin colors wouldn't set Normal (unless 'bg' is changed)
But as the root cause actually comes from `:hi Normal`, it makes sense
to still add the separate test (if `color default` here gets optimized to
become a no-op, or something).
- Checks for ECHOE, ICANON were left over from Vim code. We already
reference the symbols elsewhere without checking.
- newline_on_exit, intr_char: Both are vestigial remnants of Vim 4.x,
not implemented in Nvim. intr_char is a termios/stty feature, it's
probably not useful because users have other ways to configure their
terminals.
