- Minimum required libuv is now v1.12
- Because `uv_os_getenv` requires allocating, we must manage a map
(`envmap` in `env.c`) to maintain the old behavior of `os_getenv` .
- free() map-items after removal. khash.h does not make copies of
anything, so even its keys must be memory-managed by the caller.
closes#8398closes#9267
It's reported that the Windows widechar variants do automatically
convert from the current codepage to UTF16, which is very helpful. So
the "widechar" impls are a good direction. But libuv v1.12 does that
for us, so the next commit will use that instead.
ref #8398
ref #9267
Problem: Mode() does not indicate using CTRL-O from Insert mode.
Solution: Add "niI", "niR" and "niV" to mode() result. (closesvim/vim#3000)
612cc3888b
Problem: Sorting large numbers is not tested and does not work properly.
Solution: Add test. Fix comparing lines with and without a number.
(Dominique Pelle, closesvim/vim#4017)
a25e3d0695
- Like Vim, use set_option_value() followed by reset_option_was_set().
- Do not use set_string_default(), so the default is predictable.
This affects `:set bg&`.
- Wait until end-of-startup (VimEnter) to handle the response. The
response is racey anyways, so timing is irrelevant. This allows
OptionSet to be triggered, unlike during startup.
Suggested by ZyX in https://github.com/neovim/neovim/issues/6725#issuecomment-312197691 :
> There already is an exception if writing to a “device” (e.g. FIFO).
> It makes sense to ignore certain errors like ENOTSUP or EOPNOTSUPP
> since it is not something we or user can do anything about.
ref #6725
macOS: Try direct fsync() if F_FULLFSYNC fails.
closes#6725
ref https://github.com/vim/vim/pull/4016
vim-patch:8.1.0957
> on macOS F_FULLFSYNC fails with ENOTSUP for unsupported storage systems
> (e.g. SMB), though this is not documented in the Apple fcntl man page.
libuv fixed this in v1.25.0:
6fc797c3fe
Problem: Internal error when using pattern with NL in the range.
Solution: Use an actual newline for the range. (closesvim/vim#3989) Also fix
error message. (Dominique Pelle)
a5483448cb
tmux users are encouraged to use "tmux-256color" instead of the old
"screen-256color". Put this in your .tmux.conf :
if-shell 'infocmp tmux-256color' 'set -g default-terminal "tmux-256color"' 'set -g default-terminal "screen-256color"'
If default-terminal is "tmux-256color" AND tmux finds its terminfo, THEN
it will enable italics (regardless of whether the terminfo contains
sitm/ritm).
OTHERWISE tmux "emulates screen", which means it emits italics as
"reverse". That's unfortunate, but it's an acceptable compromise that
allows Nvim to support italics in tmux by default in compatible (and
increasingly-common) configurations.
Test case:
tmux
nvim -u NORC +'hi Comment cterm=italic' CMakeLists.txt
ref #9598
This is the conservative approach, requiring TERM=nsterm as recommended
at `:help $TERM`. It won't work with Terminal.app's default of
TERM=xterm-256color, nor in tmux.
Test case:
TERM=nsterm nvim -u NORC +'hi Comment cterm=italic' CMakeLists.txt
closes#9598
Loading existing files into a buffer is non-trivial and requires a window.
Creating an unnamed emtpy buffer is trivial and safe though, thus worth a
special case.
Change nvim_buf_set_option to use aucmd_prepbuf. This is necessary
to allow some options to be set on a not yet displayed buffer, such
as 'buftype' option.
vim-patch:7.4.1858: Add BLN_NEW to enforce buflist_new creating new buffer
grid_xx functions shouldn't randomly be called when the screen is not valid.
Nvim deterministically initializes a default screen early in main(), so the
default grid can be assumed to be allocated.
Why?
- Because we can.
- Because the TUI is just another GUI™
- Because it looks kinda nice, and provides useful context like 1 out of 100
times
Complies with "don't pay for what you don't use".
Some crashes for resizing were unfolded, add tests for those.
