Before this, --embed UIs (without --headless) would not trigger UIEnter.
For TUI, maybe UIEnter isn't useful, but:
- It is less "surprising"/special.
- Makes documentation simpler.
- When TUI becomes a coprocess, it will happen anyway.
libvterm now advertises a version number, so we can specify the minimum
required version. And this is necessary because there were breaking
changes in its API.
ref 2a590e2293
ref https://github.com/neovim/neovim/issues/10991
simplify handling of default colors
nvim is always true color internally, remove ui_rgb_attached() check.
Fix "runtime termguicolors" test. The test actually reflected broken behavior
in (parent) nvim: nvim_ui_set_option("rgb", true) was not respected by existing
:terminal instances, so all 16-palette colors became dark blue.
(Port some refactoring, but ignore "balloon" changes.)
Problem: Cannot use 'balloonexpr' in a terminal.
Solution: Add 'balloonevalterm' and add code to handle mouse movements in a
terminal. Initial implementation for Unix with GUI.
51b0f3701e
Problem: Existing color schemes don't work well with StatusLineTerm.
Solution: Don't use "reverse", use fg and bg colors. Also add
StatusLineTermNC.
05fbfdcda4
Vim added more flags for testing yet more dimensions of its Python
situation. Handle those in eval_has_provider().
vim-patch:8.0.1436: not enough information about what Python version may work
Problem: Not enough information about what Python version may work.
Solution: Add "python_compiled", "python3_compiled", "python_dynamic" and
"python3_dynamic" values for has().
ref: https://github.com/neovim/neovim/pull/10942#issuecomment-529479500
N/A:
vim-patch:8.0.0941: existing color schemes don't like StatusLineTerm
vim-patch:8.0.0937: user highlight groups not adjusted for terminal
vim-patch:8.0.0825: not easy to see that a window is a terminal window
vim-patch:8.1.1680: the command table is not well aligned
vim-patch:8.1.1994: MS-Windows: cannot build with eval but without cscope
vim-patch:8.1.2002: version number 2000 missing
vim-patch:8.1.2003: MS-Windows: code page 65001 is not recognized
vim-patch:8.1.2006: build failure with huge features but without channel feature
vim-patch:8.1.2015: terminal altscreen test still fails sometimes
vim-patch:8.1.2016: terminal altscreen test now fails on MS-Windows
`beval` patches are N/A now. See https://github.com/neovim/neovim/pull/10942#issuecomment-528029830
vim-patch:8.0.1366: 1ad022a9b8
vim-patch:8.1.0444: unnecessary check for NULL pointer
vim-patch:8.1.0652: freeing memory for balloon eval too early
vim-patch:8.1.1302: v:beval_text is not tested in Visual mode
vim-patch:8.1.1648: MS-Windows: build error with normal feaures
vim-patch:8.1.1650: warning for using uninitialized variable
vim-patch:8.1.1654: GUI: screen updates from 'balloonexpr' are not displayed
vim-patch:8.1.1708: Coverity warns for using uninitialized variable
Forcing insert-mode after the first paste-chunk seems to work, as an
alternative to a9e2bae0eb (insert-before-cursor).
NB: Dot-repeat needs to match the original action. Since a9e2bae0eb
changed paste to insert-before-cursor, dot-repeat must also. But that
makes dot-repeat unpleasant/unusual.
Problem: When starting with multiple tabs file messages is confusing.
Solution: Set 'shortmess' when loading the other tabs. (Christian Brabandt)
c75e812623
Inserting "after" the cursor in Normal-mode, for big paste-streams, is
not reliable: sometimes the text "after" the cursor ends up in the
middle of the pasted text. Maybe the cursor position is not updated?
To avoid weird behavior, always paste "before". Maybe nvim_put() or
vim.paste() can be fixed more properly later.
