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.
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
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.
Problem: If multiple paste "chunks" are streamed, chunks after the
first line are pasted into the buffer.
Solution: Check for cmdline-mode for all chunks in a paste-stream.
(We don't implement StatusLineTerm{NC}, but this patch seems generally relevant.)
Problem: if there is no StatusLine highlighting and there is StatusLineNC
or StatusLineTermNC highlighting then an invalid highlight id is
passed to combine_stl_hlt(). (Coverity)
Solution: Check id_S to be -1 instead of zero.
d6a7b3e6bb
- Workaround #10966: 'paste' option is not always reset.
- In any case there's not much reason to wait until phase=3, because
pasting in cmdline-mode skips lines after the first line (thus the
`:set paste .. :set nopaste` dance happens only ~once).
