Problem:
`termopen` has long been a superficial wrapper around `jobstart`, and
has no real purpose. Also, `vim.system` and `nvim_open_term` presumably
will replace all features of `jobstart` and `termopen`, so centralizing
the logic will help with that.
Solution:
- Introduce `eval/deprecated.c`, where all deprecated eval funcs will live.
- Introduce "term" flag of `jobstart`.
- Deprecate `termopen`.
Enabling private DEC mode 2031 tells the terminal to notify Nvim
whenever the OS theme changes (i.e. light mode to dark mode or vice
versa) or the terminal emulator's palette changes. When we receive one
of these notifications we query the terminal color's background color
again to see if it has changed and update the value of 'background' if
it has.
We only do this though if the user has not explicitly set the value of
'bg' themselves. The help text is updated slightly to hint to users that
they probably shouldn't set this value: on modern terminal emulators
Nvim is able to completely determine this automatically.
Problem:
The default unimpaired mappings display an empty line after the
command's output. This results (with default configuration) in the
`Press ENTER or type command to continue` prompt to be displayed, like
so:
```
(2 of 16): item2
Press ENTER or type command to continue
```
Solution:
The cause is that we're checking the second return value from
`pcall(vim.api.nvim_cmd, opts, {})` to determine whether the call was
successful. `nvim_cmd` returns an empty string on success, so this value
is an empty string in the successful path which we then display.
The fix is simple: check the first return value instead which is the
"status code" of the call.
Some commands don't accept "count" and only work with "range". It's not
clear why. The issue is tracked at [1], but this is a workaround for
now.
[1]: https://github.com/neovim/neovim/issues/30641
Problem:
When 'ignorecase' is set, the default keymap Q and Q would exit visual
mode.
This issue was raised in #28287 and a fix was applied in #28289.
However, `==` operator is subject to user `ignorecase` setting.
Solution:
Switching to `==#` operator would guarantee case sensitive comparison
between visual mode and linewise visual mode.
Co-authored-by: Kuanju Chen <kuanju.chen@mksinst.com>
We currently check $COLORTERM in the TUI process to determine if the
terminal supports 24 bit color (truecolor). If $COLORTERM is "truecolor"
or "24bit" then we automatically assume that the terminal supports
truecolor, but if $COLORTERM is set to any other value we still query
the terminal.
The `rgb` flag of the UI struct is a boolean which only indicates
whether the UI supports truecolor, but does not have a 3rd state that we
can use to represent "we don't know if the UI supports truecolor". We
currently use `rgb=false` to represent this "we don't know" state, and
we use XTGETTCAP and DECRQSS queries to determine at runtime if the
terminal supports truecolor. However, if $COLORTERM is set to a value
besides "truecolor" or "24bit" (e.g. "256" or "16) that is a clear
indication that the terminal _does not_ support truecolor, so it is
incorrect to treat `rgb=false` as "we don't know" in that case.
Instead, in the TUI process we only check for the terminfo capabilities.
This must be done in the TUI process because we do not have access to
this information in the core Neovim process when `_defaults.lua` runs.
If the TUI cannot determine truecolor support from terminfo alone, we
set `rgb=false` to indicate "we don't know if the terminal supports
truecolor yet, keep checking". When we get to `_defaults.lua`, we can
then check $COLORTERM and only query the terminal if it is unset.
This means that users can explicitly opt out of truecolor determination
by setting `COLORTERM=256` (or similar) in their environment.
Problem: There is no easy way to configure the behavior of the default
diagnostic "jump" mappings. For example, some users way want to show the
floating window, and some may not (likewise, some way want to only move
between warnings/errors, or disable the "wrap" parameter).
Solution: Add a "jump" table to vim.diagnostic.config() that sets
default values for vim.diagnostic.jump().
Alternatives: Users can override the default mappings to use the exact
options to vim.diagnostic.jump() that they want, but this has a couple
issues:
- While the default mappings are not complicated, they are also not
trivial, so overriding them requires users to understand
implementation details (specifically things like setting "count"
properly).
- If plugins want to change the default mappings, or configure the
behavior in any way (e.g. floating window display), it becomes even
harder for users to tweak specific behavior.
vim.diagnostic.config() already works quite well as the "entry point"
for tuning knobs with diagnostic UI elements, so this fits in nicely and
composes well with existing mental models and idioms.
The new default SwapExists autocommand displays warning text (W325) but
does not use the WarningMsg highlight group as other warnings do. Use
the WARN log level when displaying this warning.
In other words, `gx` works regardless of where it was used in
`[...](https://...)`. This only works on markdown buffers.
Co-authored-by: ribru17 <ribru17@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.
reverts e0d92b9cc2#28502
Problem:
`vim.ui.open()` has a `pcall()` like signature, under the assumption
that this is the Lua idiom for returning result-or-error. However, the
`result|nil, errmsg|nil` pattern:
- has precedent in:
- `io.open`
- `vim.uv` (`:help luv-error-handling`)
- has these advantages:
- Can be used with `assert()`:
```
local result, err = assert(foobar())
```
- Allows LuaLS to infer the type of `result`:
```
local result, err = foobar()
if err then
...
elseif result then
...
end
```
Solution:
- Revert to the `result|nil, errmsg|nil` pattern.
- Document the pattern in our guidelines.
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.
Problem:
`vim.ui.open` unnecessarily invents a different success/failure
convention. Its return type was changed in 57adf8c6e0, so we might as
well change it to have a more conventional form.
Solution:
Change the signature to use the `pcall` convention of `status, result`.
Problem:
vim.ui.open "locks up" Nvim if the spawned process does not terminate. #27986
Solution:
- Change `vim.ui.open()`:
- Do not call `wait()`.
- Return a `SystemObj`. The caller can decide if it wants to `wait()`.
- Change `gx` to `wait()` only a short time.
- Allows `gx` to show a message if the command fails, without the
risk of waiting forever.
Problem:
The `:terminal` auto-close logic does not support `&shell` that has
arguments, e.g., `/bin/bash -O globstar`.
Solution:
Join `argv` and match `&shell`. This is not perfect since `&shell` may
contain irregular spaces and quotes, but it seems to be good enough.
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()`.
Ref #21393
- Move default user commands to _defaults.lua as that now contains all
kinds of defaults rather than just default mappings and menus.
- Remove the :aunmenu as there are no menus when _defaults.lua is run.
