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.
Problem: When 'hidden' is set session creates extra buffers.
Solution: Move :badd commands to the end. (Jason Franklin)
d39e275b57
Adjust some tests in ex_cmds/mksession_spec.lua:
- 'restores same :terminal buf in splits': Buffers aren't always :badded
in the same order as they're :edited, :balted, etc, so the order of
buffers in the buffer list may change slightly now that :badd happens
afterwards.
- 'restores buffers with tab-local CWD': This is explained in a comment.
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.
Some programs behave differently when they detect that stdin is being
piped. This can be problematic when these programs are used with the job
control API where stdin is attached, but not typically used. It is
possible to run the job using a PTY which circumvents this problem, but
that includes a lot of overhead when simply closing the stdin pipe would
suffice.
To enable this behavior, add a new parameter to the jobstart options
dict called "stdin" with two valid values: "pipe" (the default)
implements the existing behavior of opening a channel for stdin and
"null" which disconnects stdin (or, if you prefer, connects it to
/dev/null). This is extensible so that other modes can be added in the
future.
Check that `wip2` does not point to the same address as `wip`, to address the
Coverity test failure from PR #14884.
Based on the `if` clauses, `free_wininfo(wip2, ...)` is only called when
`wip2->wi_win == NULL` and `wip->wi_win == wp`. I think `wip2` would only point
to the same address as `wip` in scenarios where `wp` were `NULL`, which can be
assumed otherwise based on the earlier code.
Problem: Crash when using "quit" at recovery prompt and autocommands are
triggered.
Solution: Block autocommands when creating an empty buffer to use as the
current buffer. (closesvim/vim#8506)
1d97efce0c
Problem: With 'virtualedit' set to "block" Visual highlight is wrong after
using "$". (Marco Trosi)
Solution: Do not set w_old_cursor_lcol to MAXCOL. (closesvim/vim#8495)
9cee4a1c9c
Problem: JSONC files are not recognized.
Solution: Recognize .jsonc files. (Izhak Jakov, closesvim/vim#8500)
acbb4b5720
N/A patches for version.c:
vim-patch:8.2.3081: cannot catch errors in a channel command
Problem: Cannot catch errors in a channel command.
Solution: Instead of skipping the error make it silent. (closesvim/vim#8477)
11a632d60b
vim-patch:8.2.3082: a channel command "echoerr" does not show anything
Problem: A channel command "echoerr" does not show anything.
Solution: Do not use silent errors when using an "echoerr" command.
(closesvim/vim#8494)
b836f631db
vim-patch:8.2.3094: Test_popup_atcursor_pos() fails without the conceal feature
Problem: Test_popup_atcursor_pos() fails without the conceal feature.
Solution: Add a check for the conceal feature. (Dominique Pellé,
closesvim/vim#8505)
c60e959cba
vim-patch:8.2.3098: popup window test is flaky on MS-Windows with GUI
Problem: Popup window test is flaky on MS-Windows with GUI.
Solution: Skip the check in this situation.
999db2346b
