aboutsummaryrefslogtreecommitdiff
path: root/runtime/lua/vim/ui.lua
Commit message (Collapse)AuthorAge
* docs: replace <pre> with ``` (#25136)Gregory Anders2023-09-14
|
* refactor(vim.system): factor out on_exit handlingLewis Russell2023-09-05
|
* fix(ui.open): some URLs fail on Windowsmarshmallow2023-07-21
| | | | | | | | | | | | Problem: On Windows, `explorer.exe` fails to open some URLs, for example: :lua vim.ui.open('https://devdocs.io/#q=lua%20lua_call') https://github.com/neovim/neovim/pull/23401#issuecomment-1641015704 Solution: Use rundll32 instead.
* fix(vim.ui.open): return (don't show) error messageJustin M. Keyes2023-07-05
| | | | | | | | | | Problem: Showing an error via vim.notify() makes it awkward for callers such as lsp/handlers.lua to avoid showing redundant errors. Solution: Return the message instead of showing it. Let the caller decide whether and when to show the message.
* fix(gx): visual selection, expand env varsJustin M. Keyes2023-07-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | --- Rejected experiment: move vim.ui.open() to vim.env.open() Problem: `vim.ui` is where user-interface "providers" live, which can be overridden. It would also be useful to have a "providers" namespace for platform-specific features such as "open", clipboard, python, and the other providers listed in `:help providers`. We could overload `vim.ui` to serve that purpose as the single "providers" namespace, but `vim.ui.nodejs()` for example seems awkward. Solution: `vim.env` currently has too narrow of a purpose. Overload it to also be a namespace for `vim.env.open`. diff --git a/runtime/lua/vim/_meta.lua b/runtime/lua/vim/_meta.lua index 913f1fe20348..17d05ff37595 100644 --- a/runtime/lua/vim/_meta.lua +++ b/runtime/lua/vim/_meta.lua @@ -37,8 +37,28 @@ local options_info = setmetatable({}, { end, }) -vim.env = setmetatable({}, { - __index = function(_, k) +vim.env = setmetatable({ + open = setmetatable({}, { + __call = function(_, uri) + print('xxxxx'..uri) + return true + end, + __tostring = function() + local v = vim.fn.getenv('open') + if v == vim.NIL then + return nil + end + return v + end, + }) + }, + { + __index = function(t, k, ...) + if k == 'open' then + error() + -- vim.print({...}) + -- return rawget(t, k) + end local v = vim.fn.getenv(k) if v == vim.NIL then return nil
* feat(vim.ui): vim.ui.open, "gx" without netrwmarshmallow2023-07-04
| | | | | | Co-authored-by: Mathias Fußenegger <mfussenegger@users.noreply.github.com> Co-authored-by: Justin M. Keyes <justinkz@gmail.com> Co-authored-by: ii14 <59243201+ii14@users.noreply.github.com>
* docs: naming conventions, guidelinesJustin M. Keyes2023-02-22
| | | | close #21063
* docs(gen): support language annotation in docstringsChristian Clason2022-12-02
|
* fix: vim.ui.input always calls callback #21006Steven Arcangeli2022-11-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* fix(vim.ui.input): return empty string when inputs nothing (#20883)Jongwook Choi2022-11-08
| | | | | | | | | | | 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.
* fix(vim.ui.input): accept nil or empty "opts" #191090x74696d6d792022-06-28
| | | Fix #18143
* chore: format runtime with styluaChristian Clason2022-05-09
|
* docs: typo fixes (#17859)dundargoc2022-04-15
| | | | | | | | | | Co-authored-by: Elias Alves Moura <eliamoura.alves@gmail.com> Co-authored-by: venkatesh <shariharanvenkatesh@gmail.com> Co-authored-by: zeertzjq <zeertzjq@outlook.com> Co-authored-by: Vikas Raj <24727447+numToStr@users.noreply.github.com> Co-authored-by: Steve Vermeulen <sfvermeulen@gmail.com> Co-authored-by: Evgeni Chasnovski <evgeni.chasnovski@gmail.com> Co-authored-by: rwxd <rwxd@pm.me> Co-authored-by: casswedson <58050969+casswedson@users.noreply.github.com>
* chore: fix typos (#17250)dundargoc2022-02-08
| | | | | | Co-authored-by: zeertzjq <zeertzjq@outlook.com> Co-authored-by: Dani Dickstein <daniel.dickstein@gmail.com> Co-authored-by: Axel Dahlberg <git@valleymnt.com>
* docs: add example to vim.ui.select (#17241)dundargoc2022-01-30
| | | Closes https://github.com/neovim/neovim/issues/17137
* feat(ui): add vim.ui.input and use in lsp rename (#15959)Sebastian Lyng Johansen2021-11-07
| | | | | | * vim.ui.input is an overridable function that prompts for user input * take an opts table and the `on_confirm` callback, see `:help vim.ui.input` for more details * defaults to a wrapper around vim.fn.input(opts) * switches the built-in client's rename handler to use vim.ui.input by default
* feat(ui): add `opt.kind` to `vim.ui.select` (#15838)Zachary Churchill2021-10-31
| | | Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
* fix(ui): s/format_entry/format_item to match docs (#15819)Mathias Fußenegger2021-09-27
| | | Follow up to https://github.com/neovim/neovim/pull/15771
* feat(ui): add vim.ui.select and use in code actions (#15771)Mathias Fußenegger2021-09-27
Continuation of https://github.com/neovim/neovim/pull/15202 A plugin like telescope could override it with a fancy implementation and then users would get the telescope-ui within each plugin that utilizes the vim.ui.select function. There are some plugins which override the `textDocument/codeAction` handler solely to provide a different UI. With custom client commands and soon codeAction resolve support, it becomes more difficult to implement the handler right - so having a dedicated way to override the picking function will be useful.
generated by cgit (git 2.34.1) at 2025-04-28 20:16:00 +0000