Problem:
`nvim -es` (and `nvim -Es`) is the recommended way to non-interactively
run commands/vimscript. But it enables shada by default, which is
usually not wanted.
Solution:
- Disable shada by default for `nvim -es/-Es`. This can be overridden by
`-i foo` if needed.
- Do NOT change the 'loadplugins' default.
- User config + packages _should_ be enabled by default, for both `nvim
-es` and `nvim -l`. Else any Lua packages you have can't be accessed
without `-u path/to/config`, which is clumsy.
- Use-cases:
```
nvim --headless "+Lazy! sync" +qa
would become: nvim -es "+Lazy! sync"
nvim --headless +PlugInstall +qall
would become: nvim -es +PlugInstall
```
- Opt-out (`--clean` or `-u NONE`) is much easier than opt-in (`-u
path/to/config`).
- User config/packages are analogous to pip packages, which are
expected when doing `python -c ...`.
related: 7c94bcd2d7
related: ddd0eb6f51
When a terminal application running inside the terminal emulator sets
the cursor shape or blink status of the cursor, update the cursor in the
parent terminal to match.
This removes the "virtual cursor" that has been in use by the terminal
emulator since the beginning. The original rationale for using the
virtual cursor was to avoid having to support additional UI methods to
change the cursor color for other (non-TUI) UIs, instead relying on the
TermCursor and TermCursorNC highlight groups.
The TermCursor highlight group is now used in the default 'guicursor'
value, which has a new entry for Terminal mode. However, the
TermCursorNC highlight group is no longer supported: since terminal
windows now use the real cursor, when the window is not focused there is
no cursor displayed in the window at all, so there is nothing to
highlight. Users can still use the StatusLineTermNC highlight group to
differentiate non-focused terminal windows.
BREAKING CHANGE: The TermCursorNC highlight group is no longer supported.
Problem: :sleep! not hiding the cursor is an arbitrary difference from
Vim without obvious justification, and Vim's behavior isn't
easily achievable in Nvim.
Solution: Make :sleep! hide the cursor while sleeping.
Ref:
6a01b3fcc3b5c0ade437
Problem: default for 'backspace' can be set in C code
Solution: promote the default for 'backspace' from defaults.vim to the C
code (Luca Saccarola)
closes: vim/vim#16143959ef61430
N/A patches:
vim-patch:9.1.0895: default history value is too small
vim-patch:075aeea: runtime(doc): document changed default value for 'history'
Co-authored-by: Luca Saccarola <github.e41mv@aleeas.com>
Problem: 'wildmenu' not enabled by default in nocp mode
Solution: promote the default Vim value to true, it has been enabled
in defaults.vim anyhow, so remove it there (Luca Saccarola)
closes: vim/vim#16055437bc13ea1
Co-authored-by: Luca Saccarola <github.e41mv@aleeas.com>
Problem: We use `void *` for option default values, which is confusing and can cause problems with type-correctness. It also doesn't accomodate for multitype options. On top of that, it also leads to default boolean option values not behaving correctly on big endian systems.
Solution: Use `OptVal` for option default values.
BREAKING CHANGE:
- `:set {option}<` removes the local value for all global-local options instead of just string global-local options.
- `:setlocal {option}<` copies the global value to the local value for number and boolean global-local options instead of removing the local value.
Problem:
Hidden options are documented despite being no-ops.
Solution:
Remove docs for hidden options.
Move tags for options that we plan to restore, to ":help nvim-missing".
Move tags for permanently removed options, to ":help nvim-removed".
Problem:
- `vim.highlight` module does not follow `:help dev-name-common`, which
documents the name for "highlight" as "hl".
- Shorter names are usually preferred.
Solution:
Rename `vim.highlight` to `vim.hl`.
This is not a breaking change until 2.0 (or maybe never).
Problem: Some runtime files no longer spark joy.
Solution: Kondo the place up.
Still sparks _some_ joy (moved to new `runtime/scripts` folder):
* `macros/less.*`
* `mswin.vim`
* `tools/emoji_list.lua`
No longer sparks joy (removed):
* `macmap.vim` (gvimrc file; not useful in Nvim)
* `tools/check_colors.vim` (no longer useful with new default colorscheme and treesitter)
* `macros/editexisting.vim` (throws error on current Nvim)
* `macros/justify.vim` (obsolete shim for `packadd! justify`)
* `macros/matchit.vim` (same)
* `macros/shellmenu.vim` (same)
* `macros/swapmous.vim` (same)
Problem: Current instance of last search pattern not easily spotted.
Solution: Add CurSearch highlighting. (closesvim/vim#10133)
a43993897a
Some code is superseded by later patches that are already ported.
Co-authored-by: LemonBoy <thatlemon@gmail.com>
Revert the default LSP mappings before the 0.10 release as these might
need some further consideration. In particular, it's not clear if "c"
prefixed maps in Normal mode are acceptable as defaults since they
interfere with text objects or operator ranges.
We will re-introduce default mappings at the beginning of the 0.11
release cycle, this reversion is only for the imminent 0.10 release.
Problem:
The new LSP "refactor menu" keybinding "crr" is also defined in visual
mode, which overlaps with the builtin "c".
Solution:
Use CTRL-R instead of "crr" for visual mode.
fix#28528
Based on feedback from #28324, pass -H and -I to regular grep
(available on all platforms officially supported by Neovim), and
only pass -uu to ripgrep. This makes :grep ignore binary files by
default in both cases.
Design
- Enable commenting support only through `gc` mappings for simplicity.
No ability to configure, no Lua module, no user commands. Yet.
- Overall implementation is a simplified version of 'mini.comment'
module of 'echasnovski/mini.nvim' adapted to be a better suit for
core. It basically means reducing code paths which use only specific
fixed set of plugin config.
All used options are default except `pad_comment_parts = false`. This
means that 'commentstring' option is used as is without forcing single
space inner padding.
As 'tpope/vim-commentary' was considered for inclusion earlier, here is
a quick summary of how this commit differs from it:
- **User-facing features**. Both implement similar user-facing mappings.
This commit does not include `gcu` which is essentially a `gcgc`.
There are no commands, events, or configuration in this commit.
- **Size**. Both have reasonably comparable number of lines of code,
while this commit has more comments in tricky areas.
- **Maintainability**. This commit has (purely subjectively) better
readability, tests, and Lua types.
- **Configurability**. This commit has no user configuration, while
'vim-commentary' has some (partially as a counter-measure to possibly
modifying 'commentstring' option).
- **Extra features**:
- This commit supports tree-sitter by computing `'commentstring'`
option under cursor, which can matter in presence of tree-sitter
injected languages.
- This commit comments blank lines while 'tpope/vim-commentary' does
not. At the same time, blank lines are not taken into account when
deciding the toggle action.
- This commit has much better speed on larger chunks of lines (like
above 1000). This is thanks to using `nvim_buf_set_lines()` to set
all new lines at once, and not with `vim.fn.setline()`.
When "q" is set in 'shortmess' it now fully hides the "recording @a" message
when you are recording a macro instead of just shortening to "recording". This
removes duplication when using reg_recording() in the statusline.
Related #19193
The motivation for this update is Issue #15365, where background=light
is not properly set for Nvim running from an Nvim :terminal. This can be
encountered when e.g., opening a terminal to make git commits, which
opens EDITOR=nvim in the nested terminal.
Under the implementation of this commit, the OSC response always
indicates a black or white foreground/background. While this may not
reflect the actual foreground/background color, it permits 'background'
to be retained for a nested Nvim instance running in the terminal
emulator. The behaviour matches Vim.
Problem: reloading colorscheme when not changing 'background'
Solution: Check, if the background option value actually changed,
if not, return early.
Only reload colorscheme when bg is changed
Currently the highlight groups are re-initialized and the colorscheme
(if any) is reloaded anytime 'background' is set, even if it is not
changed. This is unnecessary, because if the value was not changed then
there is no need to change highlight groups or do anything with the
colorscheme. Instead, only reload the colorscheme if the value of
'background' was actually changed.
closes: vim/vim#1370083ad2726ff
Co-authored-by: Gregory Anders <greg@gpanders.com>
Problem:
Bundled color schemes use `:hi clear` and only define Vim's highlight
groups. This results into Nvim-specific highlight groups using
definitions from Nvim's default color scheme, which are not always
linked to a Vim's highlight group.
Solution:
Restore links to Vim's highlight groups which were present before Nvim's
default color scheme update.
Currently, setting &bg at all re-initializes highlights and reloads
the active colorscheme, even if the actual value of &bg has not changed.
With https://github.com/neovim/neovim/pull/26595 this causes a
regression since &bg is set unconditionally based on the value detected
from the terminal.
Instead, only reload the colorscheme if the actual value of &bg has
changed.
Problem: Updating default color scheme produced some feedback.
Solution: Address the feedback.
Outline of the changes:
- Colors `Grey1` and `Grey2` are made a little bit more extreme (dark -
darker, light - lighter) to increase overall contrast.
- `gui` colors are treated as base with `cterm` colors falling back to
using 0-15 colors which come from terminal emulator.
- Update highlight group definition to not include attribute definition
if it is intended to staty uncolored.
- Tweak some specific highlight groups.
- Add a list of Neovim specific highlight groups which are now defined
differently in a breaking way.
- Minor tweaks in several other places related to default color scheme.
