When building with certain GCC versions, a _Float128 type is present
when setting up the ffi for unit tests.
./test/unit/helpers.lua:256: declaration specifier expected near '_Float128' at line 396
/usr/bin/luajit: /usr/share/lua/5.1/busted/runner.lua:99: attempt to concatenate local 'message' (a table value)
stack traceback:
/usr/share/lua/5.1/busted/runner.lua:99: in function 'fn'
/usr/share/lua/5.1/mediator.lua:103: in function 'publish'
/usr/share/lua/5.1/busted/modules/helper_loader.lua:21: in function 'helperLoader'
/usr/share/lua/5.1/busted/runner.lua:147: in function </usr/share/lua/5.1/busted/runner.lua:11>
/usr/bin/busted:3: in main chunk
[C]: at 0x004044a0
CMake Error at /<<PKGBUILDDIR>>/cmake/RunTests.cmake:53 (message):
Running unit tests failed with error: 1.
Since this is being pulled in by a dependency, not directly used by
nvim, just ignore the type.
Closes#7423
ruby uses batchfiles with 'cmd' extension.
gem creates batchfiles with 'bat' extension.
`gem install rails` does the following in Windows (not Cygwin):
1. Run `gem.cmd install rails` on cmd.exe
2. gem.cmd runs `ruby.exe -x gem install rails`
3. `rails` gem is installed.
`rails.bat` is created in the same directory
where ruby.exe and gem.cmd reside.
- channels: vim-patch:8.0.0018
- GUI: vim-patch:8.0.0021
- Different recursive function implementation: vim-patch:8.0.0141
- JSON handling: vim-patch:8.0.0166, vim-patch:8.0.0169, vim-patch:8.0.0170,
vim-patch:8.0.0171, vim-patch:8.0.0180
Mark vim-patch:8.0.0096 applied, since it was added in
860ecd7055.
[ci skip]
Since "builtin" terminfo definitions were implemented (7cbf52db1b),
the decisions made by tui.c and terminfo.c are more relevant. Exposing
that decision in the 'term' option helps with troubleshooting.
Also: remove code that allowed setting t_Co. `:set t_Co=…` has never
worked; the highlight_spec test asserting that nvim_set_option('t_Co')
_does_ work makes no sense, and should not have worked.
If an EOF is returned from `fgets`, `vim_fgets` might spin forever, as
it tries to consume the current line.
A `NULL` return value from `fgets` should break out of the function
(unless `errno` is `EINTR`), and then `feof` should be used to check for
the EOF condition on the stream.
The calls to `fgets` in `src/nvim/if_cscope.c` (and elsewhere) can show
communication errors to the user if a signal is delivered during its
system calls. For plugins that proxy subprocess output into cscope
requests, a `SIGCHLD` might *always* interfere with calls into `fgets`.
To see this in a debugger, put a breakpoint on `cs_reading_emsg` and
watch signals come in (with lldb, using `process handle --notify true
--pass true`). Next, run a subcommand from neovim that calls through
cscope when it returns. A tag picker plugin, like vim-picker and fzy,
with `cscopetag` and `cscopetagorder=0` set, reproduced this reliably.
The breakpoint will hit after a `SIGCHLD` is delivered, and `errno` will
be set to 4, `EINTR`.
The caller of `fgets` should retry when `NULL` is returned with `errno`
set to `EINTR`.
On startup, if running in a terminal, save the termios properties.
Use the saved termios for `:terminal` and `jobstart()` pty jobs.
This won't affect nvim spawned outside of a terminal.
questions:
- This affects `:terminal` and `jobstart({'pty'✌️true})`.
Should we be more conservative for `jobstart({'pty'✌️true})` (e.g.
pass NULL to forkpty() and let the OS defaults prevail)?
- Note: `iutf8` would not be set in that case.
