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.
Problem: getregion() can be improved (after v9.1.120)
Solution: change getregion() implementation to use pos as lists and
one optional {opt} dictionary (Shougo Matsushita)
Note: The following is a breaking change!
Currently, the getregion() function (included as of patch v9.1.120) takes
3 arguments: the first 2 arguments are strings, describing a position,
arg3 is the type string.
However, that is slightly inflexible, there is no way to specify
additional arguments. So let's instead change the function signature to:
getregion(pos1, pos2 [, {Dict}]) where both pos1 and pos2 are lists.
This is slightly cleaner, and gives us the flexibility to specify
additional arguments as key/value pairs to the optional Dict arg.
Now it supports the "type" key to specify the selection type
(characterwise, blockwise or linewise) and now in addition one can also
define the selection type, independently of what the 'selection' option
actually is.
Technically, this is a breaking change, but since the getregion()
Vimscript function is still quite new, this should be fine.
closes: vim/vim#1409019b718828d
Co-authored-by: Shougo Matsushita <Shougo.Matsu@gmail.com>
Validate the channel number before responding to an OSC 10/11 request.
When used with nvim_open_term, the channel number is unset (since there
is no process on the other side of the PTY).
There is now a new tmux 3.4 release that queries background color from
the parent terminal if background is not set in tmux, so removing the
passthrough still works when background is not set in tmux, and fixes
the incorrect detection when background is set in tmux.
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.
Comparing against the old value before setting matched the original
C implementation, but there is no reason to use this restriction. In
particular, this inhibits using OptionSet to determine when the option
was set. If users need to handle a case where the option _changed_, it
is easy to do so in an OptionSet autocommand using v:option_new and
v:option_old (and friends).
Enable 'termguicolors' automatically when Nvim can detect that truecolor
is supported by the host terminal.
If $COLORTERM is set to "truecolor" or "24bit", or the terminal's
terminfo entry contains capabilities for Tc, RGB, or setrgbf and
setrgbb, then we assume that the terminal supports truecolor. Otherwise,
the terminal is queried (using both XTGETTCAP and SGR + DECRQSS). If the
terminal's response to these queries (if any) indicates that it supports
truecolor, then 'termguicolors' is enabled.
The OptionSet autocommand does not fire until Vim has finished starting,
so setting 'background' before the VimEnter event would not fire the
OptionSet event. The prior implementation also waited until VimEnter to
set 'background', so this was a regression introduced when moving
background detection into Lua.
This fixes an error that can occur in certain pathological cases when
the autocommand fires at just the right time such that it attempts to
close the timer after the timer has already exited, but before the
scheduled callback has fired.
We now let the timer continue to run even when the autocommand deletes
itself to avoid having to repeat the cleanup code multiple times. There
is no harm in letting the timer execute if the autocommand does not
exist, as the pcall will catch the error.
