As of unibilium 1.2.1, directly manipulating unibi_var_t is deprecated.
../src/nvim/tui/tui.c: In function 'update_attrs':
../src/nvim/tui/tui.c:321:7: warning: 'i' is deprecated: use unibi_var_from_num or unibi_num_from_var instead [-Wdeprecated-declarations]
data->params[0].i = (fg >> 16) & 0xff; // red
^~~~
In file included from ../src/nvim/tui/tui.c:12:0:
/usr/include/unibilium.h:632:9: note: declared here
int i UNIBI_DEPRECATED("use unibi_var_from_num or unibi_num_from_var instead");
^
All use should go through unibi_{num,str}_from_var and
unibi_var_from_{num,str}. Wrap access of unibi_var_t behind a new
UNIBI_SET_NUM_VAR macro which uses the new functions when they're
available.
BSD Make will give preference to a BSDmakefile in the same directory
over a generic Makefile; this can be used to instruct BSD users to build
neovim with GNU Make (gmake) instead.
Otherwise, a flood of syntax errors stemming from the GNU-specific
Makefile will be displayed - which most BSD users are accustomed to, but
may confuse beginners nevertheless.
vim-patch:8.0.0300
Problem: Cannot stop diffing hidden buffers. (Daniel Hahler)
Solution: When using :diffoff! make the whole list if diffed buffers empty.
(closesvim/vim#736)
25ea054458
vim-patch:8.0.0291
Problem: Visual block insertion does not insert in all lines.
Solution: Don't bail out of insert too early. Add a test. (Christian
Brabandt, closesvim/vim#1290)
23fa81d222
vim-patch:8.0.0282
Problem: When doing a Visual selection and using "I" to go to insert mode,
CTRL-O needs to be used twice to go to Normal mode.
(Coacher)
Solution: Check for the return value of edit(). (Christian Brabandt,
closes#1290)
0b5c93a7f2
Workaround for travis issue:
https://github.com/travis-ci/travis-ci/issues/8363
Sometimes `pip3` works, sometimes not:
pyenv: pip3: command not found
The `pip3' command exists in these Python versions:
3.5
3.5.3
Tried these steps to fix the issue:
- add `python: 3.6` to top level of `.travis.yml`
- add `python3` to `addons.apt.packages` level of `.travis.yml`
- `pyenv global system 3.{4,5,6}`
- `pyenv global 3.6`
In all cases the presence or absence of `pip3` was random.
Always check for the presence of pyenv_root if pyenv is installed: if it
is not set, we don't know if it was intentional. If it wasn't
intentional, the warning is confusing (see #7176).
closes#7176
normal_redraw() usually takes care of this, but that doesn't happen
during terminal-mode.
regression by c484323dc6
steps to reproduce:
nvim -u NORC --cmd 'execute("set titlestring=" . $NVIM_LISTEN_ADDRESS) | set title | startinsert | !sleep 1' term://sh
closes#7248
vim-patch:8.0.0181
Problem: When 'cursorbind' and 'cursorcolumn' are both on, the column
highlignt in non-current windows is wrong.
Solution: Add validate_cursor(). (Masanori Misono, closesvim/vim#1372)
519d7785f4
vim-patch:8.0.0182
Problem: When 'cursorbind' and 'cursorline' are set, but 'cursorcolumn' is
not, then the cursor line highlighting is not updated. (Hirohito
Higashi)
Solution: Call redraw_later() with NOT_VALID.
e47683a091
vim-patch:8.0.0188
Problem: Using NOT_VALID for redraw_later() to update the cursor
line/column highlighting is not efficient.
Solution: Call validate_cursor() when 'cul' or 'cuc' is set.
9506cad7a1
main_loop.fast_events does not manifest as K_EVENT, because it is
processed at a different stage than main_loop.events. In order to queue
into main_loop.events, we need to go through the threadsafe
loop_schedule(), which queues into main_loop.thread_events and
eventually main_loop.fast_events. _Then_ it is safe to directly queue
into main_loop.events.
This makes it more likely that the event is treated as K_EVENT.
The "mapping" tests added in 541dde36e3 were flawed:
- Unlike op-pending mode, RPCs are _blocked_ during map-pending. So
a synchronous RPC like nvim_get_current_buf() waits until
'timeoutlen', then the mapping is canceled.
- helpers.expect() also performs a blocking RPC, so again that must not
intervene the two nvim_input() calls.
closes#6166
