The cmake file for libvterm had an empty CONFIGURE_COMMAND "", which tells cmake to skip the configure step for this dependency (even though a later patch added another, actual, CONFIGURE_COMMAND two lines below). Evidently the recently released cmake 3.18.0 is pickier about this than previous versions, causing the build to fail. Removing this line makes the build successful again.
The libcall family of functions need to use "int" for both input and
output. The output side was fixed in 9c42232 but I forgot about the
input side.
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# On branch libcallnr
# Your branch is up to date with 'upstream/master'.
#
# Changes to be committed:
# modified: src/nvim/eval/funcs.c
# modified: src/nvim/os/dl.c
#
Maintenance release for v0.4.x series.
FIXES:
fd02e6351#12701 ui: fix problem with sattr_T overflow
3e3002b90#12710 fs: Ensure FileInfo struct is initialized
e4629f203#12496 main.c: fix hang issue with recoverymode #12520f558af8b1#12209 fixed hang issue with --headless and -r option specified
cda119055#12180 TUI: block signals on suspend
8399f7357#12142 Fix issues revealed by gcc10 setting -fno-common by default
5e47cf27b netrw.vim: do not save +/* registers
5d41bfcce#11907 quickfix.c: Fix vimgrep regression
641e22913#11903 screen: add missing redraws after a message
47bd62c15 loop_close: close all handles
d2730365e loop_close: call uv_stop(), fix bug
284b398eb#11821 loop_close: timout after 2 seconds
1b2666cd2 messages: echo "line1\r\nline2" should not clear line1
1bf90bf9d#11651 API: fix crash on copy_object(kObjectTypeWindow)
fafd63626#11566 libcallnr: Use int, not int64_t, as the return type for Vim compat
972dd758c#11460 win_line: Fix crash with 'rightleft' in :terminal
4c48cf302 f_getenv/setenv: Access v_special when v_type is VAR_SPECIAL
2cd1ff762#11360 paste: Select-mode, Visual-mode
Problem: Empty group in 'tabline' may cause using an invalid pointer.
Solution: Set the group start position. (closesvim/vim#6505)
f56c95fdad
(cherry picked from commit 9443d39941)
sattr_T was defined as uint16_t. But this is not enough to handle the
24-bit colors of the terminal. To solve this problem, change it to int.
In 32bit, int may overflow. So, if it overflows, change it to ignore it
without adding more attr_entries.
fixes#12366
(cherry picked from commit 872ecf65d1)
Zero out the caller's FileInfo in all the functions which populate the
struct. The contents are considered private, so we need to ensure
it's initialized.
If the stat call fails, the buffer we get back from libuv may not have
any valid data in it, so don't copy it into the caller's FileInfo.
This was happening, expectedly, in functional/ex_cmds/write_spec.lua's
"write errors out correctly", which caused it to fail in certain
environments:
test/functional/ex_cmds/write_spec.lua:130: Expected objects to be the same.
Passed in:
(string) 'Vim(write):E212: Can't open file for writing: not a directory'
Expected:
(string) 'Vim(write):E166: Can't open linked file for writing'
In the case of recoverymode, the headlessmode was true, causing the UI
to hang without starting. Fix this problem by setting headlessmode to
true for List swap files only.
Co-authored-by: erw7 <erw7.github@gmail.com>
* fixed hang issue with --headless and -r option specified
Calling the do_more_prompt function in headless mode will freeze neovim because it is eventally in the input-accepting state (the same as waiting for --more--).
* fixed "Press ENTER or type command to continue" to be suppressed
If in headless mode, we need to exit at this point. If we continue, we will enter the normal mode and the message "Press ENTER or type command to continue" will be displayed and we will be in the input waiting state.
* fixed functional ex_cmds tests
* Revert "fixed "Press ENTER or type command to continue" to be suppressed"
This reverts commit a02dc40e3b.
* Revert "fixed functional ex_cmds tests"
This reverts commit 3bdb8da20a.
* fixed conditional again
* added test for fixed hang issue with --headless (#11386)
(cherry picked from commit c6dc397801)
As gcc10 uses -fno-common by default, global variables declared with the
same name more than once is not allowed anymore revealing this issue.
We need to define it as extern to access it.
See also https://bugzilla.redhat.com/show_bug.cgi?id=1799680
Instead of declaring an enum, this creates a global variable. As gcc10
uses -fno-common by default, global variables declared with the same
name more than once is not allowed anymore revealing this issue.
Each time this header is included, we define the enum name as a global
variable.
See also https://bugzilla.redhat.com/show_bug.cgi?id=1799680
Instead of declaring an enum, this creates a global variable. As gcc10
uses -fno-common by default, global variables declared with the same
name more than once is not allowed anymore revealing this issue.
Each time this header is included, we define the enum name as a global
variable.
See also https://bugzilla.redhat.com/show_bug.cgi?id=1799680
Instead of declaring an enum, this creates a global variable. As gcc10
uses -fno-common by default, global variables declared with the same
name more than once is not allowed anymore revealing this issue.
Each time this header is included, we define the enum name as a global
variable.
See also https://bugzilla.redhat.com/show_bug.cgi?id=1799680
Previously, the "precedes" character would be rendered on every row
when w_skipcol > 0 (i.e., when viewing a single line longer than the
entire screen), instead of just on the first row. Make sure to only
render it on the first row in this case.
Add a test for this behavior.
Fix documentation for the "precedes" character, which erroneously
stated that it was only active when wrap mode was off.
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
