Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

vim.fn.inputlist quirks #112

Closed
ranjithshegde opened this issue Oct 25, 2022 · 9 comments
Closed

vim.fn.inputlist quirks #112

ranjithshegde opened this issue Oct 25, 2022 · 9 comments
Labels
bug Something isn't working

Comments

@ranjithshegde
Copy link
Contributor

Firstly, apologies as I keep coming here with more issues and not fixes!

Is there a config option or perhaps making it a default behavior to always keep the prompt window open until choice for vim.fn.inputlist made or exited?

With orgmode plugin which heavily uses inputlist for a variety of functionality, from opening files to exporting pdfs, the popup view for choice stays on for a couple of seconds and disappears, like this

Peek 2022-10-25 09-27

On the other hand, I dont know if this is chiefly a problem of inputlist. I tried to reproduce with a simple example and it works as expected

Peek 2022-10-25 09-35

Logs
Since this is not exactly an error, there are no logs

Noice config

    require('noice').setup {
        cmdline = {
            view = 'cmdline',
            view_search = 'cmdline',
            format = {
                inc_rename = { pattern = '^:%s*IncRename%s+', icon = '', ft = 'text' },
            },
        },
    }
@ranjithshegde ranjithshegde added the bug Something isn't working label Oct 25, 2022
@folke
Copy link
Owner

folke commented Oct 25, 2022

I just pushed an update that doesn;t hide mini messages when the ui is blocking. I already did the same for nvim-notify.

This probably fixes your issue. Can you test it?

@ranjithshegde
Copy link
Contributor Author

@folke
Works great now!
Thanks

@gennaro-tedesco
Copy link

gennaro-tedesco commented Oct 25, 2022

Sorry to comment on a closed issue, but somewhat related to vim.fn.inputlist/input. Invoking vim.fn.input I noticed that it does not fall under the formatting options provided for cmdline (or similar patterns): what is the right way to control the options of the vim prompts (like vim.fn.confirm/input and the like)?

To be more clear: if I set specific options for formatting certain cmdline patterns (say like in the README) the prompts that display with input or confirm do not undergo the same behaviour (for instance they don't respect the highlight groups or titles that are set), thus I presume they need special format patterns to be included?

@folke
Copy link
Owner

folke commented Oct 25, 2022

For confirm, you can configure the confirm view. Check the code for that.

Configure it with config.views.confirm to override any of the deafult settings.

As for input and the like, it's not that simple, since it comes in as an event=msg_show, kind=. You can add custom routes for that, but there's no way to know if a message is coming from input or trigered by let's say :ls.

You can submit a feature request to Neovim for that :)

@folke
Copy link
Owner

folke commented Oct 25, 2022

Wait, I'm wrong, apparently input comes in as a cmdline. Will see to make this configurable!

@folke
Copy link
Owner

folke commented Oct 25, 2022

@gennaro-tedesco just pushed an update that makes this configurable. Check the docs b645e30

Default config, adds NoiceCmdlineInput as hl group for the prompt, removes the icon and sets the title to Input

@gennaro-tedesco
Copy link

Ooops, I see that confirm is there, my bad. Thank you for looking into input, obviously this is just nitpicking on things, do dedicate the time to more urgent matters :)

@folke
Copy link
Owner

folke commented Oct 25, 2022

@gennaro-tedesco input is fixed. See my previous comment :)

@gennaro-tedesco
Copy link

Woow, you're faster than we can check :D

Thank you for all the effort really.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants