This function accepts a path to a file and prompts the user if the file
is trusted. If the user confirms that the file is trusted, the contents
of the file are returned. The user's decision is stored in a trust
database at $XDG_STATE_HOME/nvim/trust. When this function is invoked
with a path that is already marked as trusted in the trust database, the
user is not prompted for a response.
Followup to #20883
Related: #18144
This patch changes the behavior of the default `vim.ui.input` when the user
aborts with `<C-c>`. Currently, it produces an error message + stack and causes
`on_confirm` to not be called. With this patch, `<C-c>` will cause `on_confirm`
to be called with `nil`, the same behavior as when the user aborts with `<Esc>`.
I can think of three good reasons why the behavior should be this way:
1. Easier for the user to understand** It's not intuitive for there to be two
ways to abort an input dialog that have _different_ outcomes. As a user,
I would expect any action that cancels the input to leave me in the same
state. As a plugin author, I see no value in having two possible outcomes for
aborting the input. I have to handle both cases, but I can't think of
a situation where I would want to treat one differently than the other.
2. Provides an API that can be overridden by other implementations** The current
contract of "throw an error upon `<C-c>`" cannot be replicated by async
implementations of `vim.ui.input`. If the callsite wants to handle the case
of the user hitting `<C-c>` they need to use `pcall(vim.ui.input, ...)`,
however an async implementation will instantly return and so there will be no
way for it to produce the same error-throwing behavior when the user inputs
`<C-c>`. This makes it impossible to be fully API-compatible with the
built-in `vim.ui.input`.
3. Provides a useful guarantee to the callsite** As a plugin author, I want the
guarantee that `on_confirm` will _always_ be called (only catastrophic errors
should prevent this). If I am in the middle of some async thread of logic,
I need some way to resume that logic after handing off control to
`vim.ui.input`. The only way to handle the `<C-c>` case is with `pcall`,
which as already mentioned, breaks down if you're using an alternative
implementation.
- If Nvim was just started, don't create a new tab.
- Name the buffer "health://".
- Use "help" syntax instead of "markdown". It fits better, and
eliminates various workarounds.
- Simplfy formatting, avoid visual noise.
- Don't print a "INFO" status, it is noisy.
- Drop the ":" after statuses, they are already UPPERCASE and highlighted.
Update runtime files
https://github.com/vim/vim/commit/76db9e076318cb0ae846f43b7549ad4f2d234c0b
- `col()`'s example was changed to use `:echowin` so that the message can be
seen with `showmode`. Use "\n" to force a hit-enter instead as `:echowin`
isn't ported.
- Replace interpolated string usage in syntax/modula3.vim (not ported).
- Add a space after the `wincmd =` examples in `*CTRL-W_=*` so that the inlined
code is highlighted properly when followed by a full stop.
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Previously man.lua would use the `env` field in the parameters of
`vim.loop.spawn` to override things like MANPAGER. This caused issues on
NixOS since `spawn` will _override_ the environment rather than _append_
to it (and NixOS relies on a heavily modified environment). Using the
`env` command to append to the environment solves this issue.
fix(vim.ui.input): return empty string when inputs nothing
The previous behavior of `vim.ui.input()` when typing <CR> with
no text input (with an intention of having the empty string as input)
was to execute `on_confirm(nil)`, conflicting with its documentation.
Inputting an empty string should now correctly execute `on_confirm('')`.
This should be clearly distinguished from cancelling or aborting the
input UI, in which case `on_confirm(nil)` is executed as before.
Adds a `name` key to the opts dict passed to Lua command callbacks
created using `nvim_create_user_command()`. This is useful for when
multiple commands use the same callback.
Note that this kind of behavior is not as strange as one might think,
even some internal Neovim commands reuse the same internal C function,
differing their behavior by checking the command name. `substitute`,
`smagic` and `snomagic` are examples of that.
This will also be useful for generalized Lua command preview functions
that can preview a wide range of commands, in which case knowing the
command name is necessary for the preview function to actually be able
to execute the command that it's supposed to preview.
- `:write ++p foo/bar/baz.txt` should create parent directories `foo/bar/` if
they do not exist
- Note: `:foo ++…` is usually for options. No existing options have
a single-char abbreviation (presumably by design), so it's safe to
special-case `++p` here.
- Same for `writefile(…, 'foo/bar/baz.txt', 'p')`
- `BufWriteCmd` can see the ++p flag via `v:cmdarg`.
closes#19884
Error detected while processing function tutor#TutorCmd[38]..BufReadPost Autocommands for "*":
Error executing lua callback: ...llar/neovim/HEAD-cc5b736/share/nvim/runtime/filetype.lua:21: Error ex
ecuting lua: ...llar/neovim/HEAD-cc5b736/share/nvim/runtime/filetype.lua:22: Vim(let):E158: Invalid bu
ffer name: .
stack traceback:
[C]: in function 'nvim_cmd'
...llar/neovim/HEAD-cc5b736/share/nvim/runtime/filetype.lua:22: in function <...llar/neovim/HE
AD-cc5b736/share/nvim/runtime/filetype.lua:21>
[C]: in function 'nvim_buf_call'
...llar/neovim/HEAD-cc5b736/share/nvim/runtime/filetype.lua:21: in function <...llar/neovim/HE
AD-cc5b736/share/nvim/runtime/filetype.lua:10>
stack traceback:
[C]: in function 'nvim_buf_call'
...llar/neovim/HEAD-cc5b736/share/nvim/runtime/filetype.lua:21: in function <...llar/neovim/HE
AD-cc5b736/share/nvim/runtime/filetype.lua:10>
Closes https://github.com/neovim/neovim/issues/20920
Problem: assert_fails() checks the last error message.
Solution: Check the first error, it is more relevant. Fix all the tests
that rely on the old behavior.
https://github.com/vim/vim/commit/9b7bf9e98f06ece595fed7a3ff53ecce89797a53
Skip test_listener.vim, test_textprop.vim, test_viminfo.vim.
Skip test_python2.vim: affected line fails and hasn't been ported.
Skip test_python3.vim: affected lines fail and haven't been ported.
Skip CHECK_LIST_MATERIALIZE.
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Since version 3.2 tmux has had the ability to read/write buffer contents
from/to the system clipboard, if the underlying terminal emulator
supports it. Enable this feature when we can detect that tmux supports
it.
Problem: Insufficient testing for invalid function arguments.
Solution: Add more tests. (Yegappan Lakshmanan, closesvim/vim#5988)
https://github.com/vim/vim/commit/99fa721944dda9d07c53c907c33466728df5c271
Omit test_listener.vim: changed again in patch 8.2.1183.
Omit test_textprop.vim: changed again in patch 8.2.1183.
Cherry-pick quickfix feature checks from patch 8.1.2373.
Omit Test_saveas() change: duplicate and removed in patch 8.2.0866.
Problem: Various functions not properly tested.
Solution: Add more tests, especially for failures. (Yegappan Lakshmanan,
closesvim/vim#5843)
https://github.com/vim/vim/commit/0e05de46226eb4e5ea580beefa71831f92d613d3
Cherry-pick test changes from patch 8.2.0427 and skip Test_has().
Cherry-pick Test_complete_wildmenu() change from patch 8.2.4339.
