When ml_add_stack() needs to increase the size of the empty stack,
buf->b_ml.ml_stack is NULL and is used as argument in memmove().
This is undefined behaviour. Declaration of memmove() in string.h:
extern void *memmove (void *__dest, const void *__src, size_t __n)
__THROW __nonnull ((1, 2));
When splitting the window (win_split_ins), function win_new_width is
already called before the height has been set. This calls
terminal_resize, which passes a height of 0 on to libvterm, which
doesn't handle a height of 0 properly.
A fix is already in place in terminal.c for not passing on the height,
but strictly speaking, it doesn't make sense for window to call
terminal_resize when it isn't initialized completely yet.
Error messages in general should be namespaced, especially in the
context of a shell. Given the possibility of a backgrounded job printing
messages to standard output/error, namespacing these messages should
avoid any confusion as to where the message came from.
Helped-by: Scott Prager <splinterofchaos@gmail.com>
Helped-by: oni-link <knil.ino@gmail.com>
This removes the need for preprocessor defines as array indices, and
brings error handling more in line with other files, which for the most
most part to use constant strings (also, see `globals.h`).
Helped-By: Nicolas Hillegeer <nicolas@hillegeer.com>
Making an environment variable empty can be a way of unsetting it for
platforms that don't support unsetenv(). In most cases, we treat empty
variables as having been unset. For all others, use os_env_exists().
- Create a private libuv loop instead of re-using uv_default_loop(), to
avoid conflict[1] with existing watcher(s) on the fd.
- Expose the global "input" fd as a getter instead of a mutable global.
[1] .deps/build/src/libuv/src/unix/core.c:833:
uv__io_stop: Assertion `loop->watchers[w->fd] == w' failed.
If stdin is non-blocking, many tools (e.g. cat(1), read(1)) which assume
that stdin is blocking, will break in odd ways:
read: read error: 0: Resource temporarily unavailable
cat: -: Resource temporarily unavailable
rm: error closing file
libuv puts stdin in nonblocking mode, and leaves it that way at exit
(this is apparently by design). So, before this commit, this always
works (because the shell clobbers O_NONBLOCK):
$ nvim --cmd q
$ read
...but these forms do _not_ work:
$ nvim --cmd q && read
$ echo foo | nvim --cmd q && read
$ nvim && read
After this commit, all of the above forms work.
Background:
437b4397b9 (diff-41f4d294430cd8c36538999d62681ae2)https://github.com/fish-shell/fish-shell/issues/176#issuecomment-15800155
- bash (and other shells: zsh, tcsh, fish), upon returning to the
foreground, always sets fd 0 back to blocking mode. This practice only
applies to stdin, _not_ stdout or stderr (in practice these fds may be
affected anyways).
- bash/zsh/tcsh/fish do _not_ restore the non-blocking status of stdin
when _resuming a job_.
- We do _not_ save/restore the original flags visible to
fcntl(F_[SG]ETFL), because (counterintuitively) that isn't expected.
Helped-by: oni-link <knil.ino@gmail.com>
Closes#2086Closes#2377
---
Note: The following implementation of stream_set_blocking() was
discarded, because it resulted in a failed libuv assertion[1]:
int stream_set_blocking(int fd, bool blocking)
{
uv_pipe_t stream;
uv_pipe_init(uv_default_loop(), &stream, 0);
uv_pipe_open(&stream, fd);
int retval = uv_stream_set_blocking((uv_stream_t *)&stream, blocking);
uv_close((uv_handle_t *)&stream, NULL);
return retval;
}
[1] .deps/build/src/libuv/src/unix/core.c:833: uv__io_stop: Assertion `loop->watchers[w->fd] == w' failed.
When maximizing the window, often only lines would be detected properly
with the `try_resize` handler being called immediately.
Fixes https://github.com/neovim/neovim/issues/2322.
