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));
The executable 'python' can refer to either Python 2 or Python 3. Add a
check to only accept Python 2 interpreters as providers for +python.
Also improve the error messages.
Resolves#2734.
I could not find a reference to NVIM_PYTHON_PYTHON_LOG anywhere, and
python-client looks for NVIM_PYTHON_LOG_FILE.
~/.nvimlog appears to be hardcoded and enabled by default. This would
need to be adjusted when this changes.
`provider#pythonX#Error` and `provider#pythonX#Prog` are currently meant
for debugging only (the error message is not being used), and should
therefore be defined always, especially in case of errors.
Ref: https://github.com/neovim/neovim/pull/2549#issuecomment-98607580
Piping input into nvim causes the helptags generation to hang. For
example, the following does not work:
yes | nvim -c "helptags ."
The helptags are generated during installation with a command similar
to the one above, using CMake's execute_process to call nvim.
As execute_process does not use an intermediate shell, the following
will cause the installation to hang:
yes | make install
pacaur, an Arch Linux package helper, uses a similar command to
install packages [1], and thus can currently not be used to install
Neovim.
This commit adds a workaround to GenerateHelptags.cmake to circumvent
this problem.
[1] 22c00a3d05/pacaur (L825)
When checking code with check_c_source_compiles, the "check variable"
(for the _FORTIFY_SOURCE detection: previously _FORTIFY_SOURCE_ACCEPTABLE, now
HAS_ACCEPTABLE_FORTIFY) is passed to the compiler like
-D_FORTIFY_SOURCE_ACCEPTABLE. This throws off hardening-wrapper [1],
which then NOT sets _FORTIFY_SOURCE=2 for the check, assuming it had already
been set manually as it detected -D_FORTIFY_SOURCE*. Renaming the "check
variable" to not match this pattern works around this problem.
[1] https://github.com/thestinger/hardening-wrapper
- Removed mention of many options which don't exist anymore.
- Add new tags for some new options (e.g., -v)
While here, also remove a few X11 references.
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>
