Add a new default autocommand to limit syntax highlighting
synchronization in the command window. This refactors the nvim_terminal
autocommand out of main() and into a new init_default_autocmds()
function, which is now part of the startup process and can be further
extended with more default autocommands down the road.
ref #6289#6399
syn_name2id and syn_check_group go brr.
Note: this has impact mostly when using multiple filetypes,
as the old syn_name2id was optimized to return latest
added groups quickly (which will be the latest filetype)
Remove syncolor.vim in favor of defining the default highlight groups
directly in `init_highlight`. This approach provides a number of
advantages:
1. The highlights are always defined, regardless of whether or not the
syntax regex engine is enabled.
2. Redundant sourcing of syntax files is eliminated (syncolor.vim was
often sourced multiple times based on how the user's colorscheme file
was written).
3. The syntax highlighting regex engine and the highlight groups
themselves are more fully decoupled.
4. Removal of the confusing `:syntax on` / `:syntax enable` dichotomy
(they now both do the same thing).
This approach also correctly solves a number of bugs related to
highlighting (#15176, #12573, #15205).
This fixes an issue introduced in #14771 (fix: source syncolors.vim
before startup scripts) that affected highlights for users who set
'background' to light in their startup script. Because syncolor.vim
checks for the value of &background, it was always setting up the 'dark'
background colors, which looked wrong for users using light backgrounds.
The primary benefit of #14771 is that it decoupled highlighting from the
syntax engine. This is useful for e.g. treesitter, which still makes use
of highlights even if the syntax engine is disabled. For this reason, it
is still worthwhile to source syncolor.vim separately from synload.vim,
which #14771 accomplishes. However, we should still source syncolor.vim
after the user startup scripts, to ensure that we are respecting the
options the user sets.
Another corollary benefit is that this reduces some redundancy in
highlight definitions, since we now only source syncolors.vim if the
user did not already enable a colorscheme.
lua is used as part of implementation for more core features. As an
example, every user keypress will invoke a lua function to check for
keypress handlers (regardless if they are registered or not). Thus not
starting lua until it is first used doesn't make much sense anymore.
nlua_enter was also needed due to the earlier stateful &rtp
translation, which by now have been made stateless.
This fixes an issue (#12573) where colorscheme files are sourced twice
upon startup. This occurs when the startup script calls `:colorscheme`,
which sets the `g:colors_name` global variable. When syntax highlighting
is enabled in `syn_maybe_enable()` the `syntax.vim` script is sourced
which in turn sources `synload.vim`. This script checks to see if
`g:colors_name` is set and, if so, runs
exe "colors " . colors_name
This is done to ensure that highlight groups are defined before enabling
the syntax highlighting engine.
Instead, source syncolors.vim before the startup scripts which sets up
default highlights and only load the full syntax engine after
the startup scripts or when the user runs `:syntax on`. Add a guard
variable `did_syncolor` to prevent syncolor.vim from being sourced
twice and remove the line mentioned above from synload.vim so that
the colorscheme file is not re-sourced when the syntax engine is loaded.
"syntax on" overwrites existing highlight groups, while "syntax enable"
just sets missing groups. This change prevents user defined highlights in
init.vim/lua to get overwritten. The manual recommends "syntax enable" for
new configurations anyway, "on" command was probably used as it is the
implicit default.
Problem: Mode is not cleared when leaving Insert mode with mapped Esc.
Solution: Clear the mode when redraw_cmdline is set. (closesvim/vim#4269)
4c25bd785a
Problem: When Vim exits because of a signal, VimLeave is not triggered.
(Daniel Hahler)
Solution: Unblock autocommands when triggering VimLeave. (closesvim/vim#4818)
c7226684c8
Problem: When reading from stdin dup() is called twice.
Solution: Remove the dup() in main.c. (Ken Takata, closesvim/vim#7110)
204ade6bcb
N/A patches for version.c:
vim-patch:8.2.2109: "vim -" does not work well when modifyOtherKeys is enabled
Problem: "vim -" does not work well when modifyOtherKeys is enabled and a
shell command is executed on startup.
Solution: Only change modifyOtherKeys when executing a shell command in raw
mode.
8a3da6a368
vim-patch:8.2.2110: cannot use ":shell" when reading from stdin
Problem: Cannot use ":shell" when reading from stdin. (Gary Johnson)
Solution: Revert patch 8.2.1833.
8e1cbb55c3
vim-patch:8.2.2111: GTK: menu background is the same color as the main window
Problem: GTK: Menu background is the same color as the main window.
Solution: Fix white space around the test in another way. (closesvim/vim#7437,
closesvim/vim#7427)
023fd5d213
vim-patch:8.2.2113: MS-Windows GUI: crash after using ":set guifont=" four times
Problem: MS-Windows GUI: crash after using ":set guifont=" four times.
Solution: Check for NULL pointer. (Ken Takata, closesvim/vim#7434)
1b3e0727ce
vim-patch:8.2.2116: MS-Windows GUI: test for 'guifont' is incomplete
Problem: MS-Windows GUI: test for 'guifont' is incomplete.
Solution: Set 'renderoptions'. (Christian Brabandt)
2c78a772fd
vim-patch:8.2.2118: dead code in the job support
Problem: Dead code in the job support. (Dominique Pellé)
Solution: Define USE_ARGV before checking for it.
f46bf5204c
vim-patch:8.2.2119: GTK3: status line background color is wrong
Problem: GTK3: status line background color is wrong.
Solution: Don't change the code for earlier GTK3 versions. (closesvim/vim#7444)
7988a6f0e9
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.
Problem: Too many #ifdefs.
Solution: Graduate the +autocmd feature. Takes away 450 #ifdefs and
increases code size of tiny Vim by only 40 Kbyte.
f2bd8ef2b4
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
