These options were previously global. A global-local window option
behaves closer to a global option "per default" (i e with :set),
but still supports local behavior via :setl
Also this restores back-compat for nvim_set_option("fcs", ...)
which are currently broken on 0.4.x but worked in earlier versions
- Move uv_stop(), it still causes a "leak" on exit somehow.
- Tenatively restore `UV_RUN_DEFAULT`. It shouldn't hang since we
clobber the handles via `uv_walk((h)=>uv_close(h))`. Although this
still "leaks" on exit, it's faster than the 2-second timeout.
fix#11820fix#7376
- Call uv_stop().
- Restore `uv_loop_close` condition (braindead cosmetic change from
a2efc9cf8b that caused uv_loop_close *not* to be called if
wait=false, sorry).
Not doing `uv_walk(() => uv_close)`: see source comment for explanation.
fix#11820fix#7376
Q: Should we restore use of `UV_RUN_DEFAULT`/`UV_RUN_ONCE` (removed in
a2efc9cf8b)?
A: The while-loop (hopefully) achieves the same purpose while avoiding
a hang.
Problem: On Windows with the MSVC build, gettext-translation
"Questa è già la" displays as "Questa <e8> gi<e0> la".
Solution: Fix iconv detection iconv when building gettext.
So HAVE_ICONV is correctly defined when building nvim.
* fix gettext mb chars on MSVC
* fix libintl detection failure on MSVC
fixes#11749
Vim's documentation simply states that libcallnr() should be used "for a
function that returns an int". Based on the tests, code, and common
syscall interfaces, this should likely be taken literally instead of
trying to apply some well-defined type lipstick.
Notably, this change fixes Test_libcall_libcallnr on hppa (a 32-bit
big-endian system).
fixes#11438
Backtrace:
0 schar_from_ascii ( p=0x801cc9e112c3 <error: Cannot access memory at address 0x801cc9e112c3>, c=32 ' ') at ../src/nvim/screen.c:5263
1 0x00007f31460eccc5 in win_line (wp=wp@entry=0x7fffc9df6230, lnum=lnum@entry=11, startrow=startrow@entry=10, endrow=41, nochange=false, number_only=number_only@entry=false) at ../src/nvim/screen.c:4025
2 0x00007f31460eed8e in win_update (wp=wp@entry=0x7fffc9df6230) at ../src/nvim/screen.c:1403
3 0x00007f31460f011f in update_screen (type=<optimized out>) at ../src/nvim/screen.c:502
4 0x00007f3146138ef4 in normal_redraw (s=s@entry=0x7fffd0a5f700) at ../src/nvim/normal.c:1247
5 0x00007f314613b159 in normal_check (state=0x7fffd0a5f700) at ../src/nvim/normal.c:1324
6 0x00007f31460accfe in state_enter (s=0x7fffd0a5f700) at ../src/nvim/state.c:28
7 0x00007f3146143099 in normal_enter (cmdwin=<optimized out>, noexmode=<optimized out>) at ../src/nvim/normal.c:463
8 0x00007f314618b541 in main (argc=<optimized out>, argv=<optimized out>) at ../src/nvim/main.c:580
(cherry picked from commit 1bb7ea189e)
Multiple Debian builds were failing these tests:
Failures:
From test_environ.vim:
Found errors in Test_external_env():
function RunTheTest[37]..Test_external_env line 16: Expected '' but got 'FOO=null\n'
Found errors in Test_getenv():
function RunTheTest[37]..Test_getenv line 2: Expected v:null but got v:false
Found errors in Test_setenv():
function RunTheTest[37]..Test_setenv line 5: Expected v:null but got 'null'
This is because nvim has a separate tag (`v_special`) in `typval_T` for
special variables, whereas vim re-uses the `v_number` tag.
On little-endian architectures, using the incorrect tag is not an issue
because the byte representation is the same. However, on big-endian
systems this caused the `v_number == kSpecialVarNull` checks to fail,
and the non-special code to execute.
Depending on the lua version, 6 might get used instead of
2 here, which causes test failures in upstream builds.
This was fixed as part of #11206 on master
I/O in Catalina is currently known to be broken. This commit works
around a pesky bug and also makes the code more consistent by removing
the mix of C file and standard I/O.
Fixes https://github.com/neovim/neovim/issues/11196
(cherry picked from commit d0efc1c906)
When using TUI host terminal should take care of this (regardless
if 'termguicolors' is active or not). For GUI the behavior doesn't make
sense (GUI should display bold attr as bold always).
(cherry picked from commit b772b86d2b)
This aligns with `terminfo_stop`, which also flushes the buffer
after disabling things.
This ensures Neovim gets the response to the terminal background query
before exiting (`nvim -u NONE -cq` with e.g. urxvt or kitty).
Caveats:
* With kitty this causes some "flickering", likely since the alternate
screen is being setup with `nvim -u NONE -cq`, whereas it would not be
processed otherwise before quitting (as with the background query).
* tmux after this patch may print ^[[I (CSI I / FocusGained) after
`nvim -u NONE -cq`.
Fixes https://github.com/neovim/neovim/issues/11062
Ref: https://github.com/neovim/neovim/issues/11181
"smglr" was added for TERM=xterm recently to the terminfo database,
which causes display issues with terminals that use `TERM=xterm` by
default for themselves, although not supporting it.
This patch makes "smglr" to be ignored then.
Fixes https://github.com/neovim/neovim/issues/10562
Problem: ":lang messages en_US.UTF-8" no longer overrides the language
detected from the environment (at startup).
Solution: In os_setenv, special-case "LC_ALL", "LANG", et al. to use
putenv_s instead of uv_os_setenv.
fixes#11045
