-
Notifications
You must be signed in to change notification settings - Fork 137
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
Add confirmation window options #344
Conversation
Hi, I also wanted this feature, so I implemented it myself master...jedrzejboczar:oil.nvim:jb/confirm-dialog-config and then I checked existing PRs just to realize that someone else has already created such a PR. So basically I am all for merging this PR :) What's funny is that my implementation is almost identical, even the naming of config options is similar. The main difference that I would suggest is to use
As these tables are Lua lists (only numeric keys starting from 1) it would be simpler to use local cancel_keys = vim.list_extend({ "q", "<C-c>", "<Esc>" }, config.confirmation.cancel.keymaps) Note that |
Thanks for your help @jedrzejboczar i updated the pr to include
My original thought was that those mappings are "expected" to work to cancel an action or close a window but i think you are right on this. Something like
Maybe not the best naming. Let me know your thoughts on this |
* move the config from under the `confirmation` key to the `preview` key, which is already in use for customizing the window * fully default to yes/no, keeping the o/c keybindings for backwards compatibility * make all of the `cancel` keybindings explicit (q, C-c, esc) * more dynamically choose highlighting of the action labels
I pulled this locally to poke around and here's my proposal: instead of making this configurable, what about just changing the defaults to Yes/No? I've pushed back on doing this before, but I'm willing to abandon my original reasoning and accept this as a reasonable default. But once that is the default, is there any reason to customize it? I don't think most people would want to change it to something else. What do you think? |
Thanks for taking the time to test it. |
@omelette-watin why do you think that allowing for configuration is better? Do you have a use case for different labels/keymaps? |
@stevearc in my opinion, giving option for configuration presents the advantage to avoid similar pull requests on the future for some other use cases that some users might have The only drawback that i see is a bit heavier config. But, as i said i’m really happy with your full transition to yes/no, so if you just to keep it like that it’s fine by me! Anyway, thanks for taking the time to answer this pr and for this amazing plugin ! |
I'd also vote for leaving configuration options, for the same reason - avoiding issues like this from users. While I don't think that it is very important to have configurable labels, I'd say it is good to have configurable keymaps. It would probably be best to have something like But it's also completely fair if you just want to avoid more configuration options. |
I'm already a little unhappy with the amount of configuration options that oil has, and I really want to avoid adding more where it's not necessary. I don't think anyone will want the labels to change from the new values, and the keymaps can be adjusted on the user side, as explained in this comment on an earlier issue. I'll merge as-is for now. If a strong need arises in the future to add configuration options, I'll reconsider at that time. Thanks for the PR! |
Hey,
First off, big shoutout to everyone involved in this project – I love it !
I'm a bit more used to [Y]es or [N]o rather than [O]k or [C]ancel tho, so I thought it would be cool to make both the labels and key mappings configurable to suit different preferences.
I dont have a lot of experience in lua so i don't know if this PR respects good practices (especially regarding the
mergeTables
fn).