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>
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>
Prefer typographic single quotes instead of straight double quotes.
This avoids confusion when double quotes are used as part of arguments.
Annotate EOF as a "defined variable".
Assuming mandoc is used, `apropos Dv=EOF` should now work.
Clarify in parentheses what a hyphen is, as users might only know it
as a "dash". The same was already done for colons.
Group environment variables more logically.
Reviewed-by: Felipe Morales <hel.sheep@gmail.com>
Reviewed-by: Ian Ker-Seymer <i.kerseymer@gmail.com>
