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

Re-instate 'q' to close diffview.nvim #1625

Open
daniel-odrinski opened this issue Jan 8, 2025 · 4 comments
Open

Re-instate 'q' to close diffview.nvim #1625

daniel-odrinski opened this issue Jan 8, 2025 · 4 comments

Comments

@daniel-odrinski
Copy link

daniel-odrinski commented Jan 8, 2025

First off, I want to thank you for building this awesome Git plugin for Neovim! It is by far my favourite way of using Git.

Is your feature request related to a problem? Please describe.
I used to be able to close diffview.nvim views opened by Neogit, by pressing 'q'.
I noticed that after the changes to integrate diffview.nvim better for conflict resolution, this functionality has been removed.

Describe the solution you'd like
It would be great if this could be re-instated, such that I don't need to ':tabclose' each time I open diffview.nvim.

Describe alternatives you've considered
Mapping ':tabclose' to 'q' in my neovim configuration, but this is not ideal for me.

Additional context
3f09878#diff-a4c38f6445f8607627a0b1273486ce8b1b04199e9128b6ec479334b5286f4fe4L113-L121

@SheffeyG
Copy link
Contributor

SheffeyG commented Jan 9, 2025

There's a workaround via configuring it in diffview
sindrets/diffview.nvim#96

@daniel-odrinski
Copy link
Author

daniel-odrinski commented Jan 9, 2025

Thank you @SheffeyG, I'll have a look and maybe give it a try :)

@CKolkey
Copy link
Member

CKolkey commented Jan 9, 2025

Sadly, this is one of those features that's impossible to get right for everyone. When I added the "close" mappings for people, I got complaints that I was messing with a user's mappings. I remove it, and others ask for it back 😅 There's no winning!

In the past, we needed some "on close" logic, so overloading the close function got us that, and binding it for user's was a must. But, we don't need that anymore.

Given that, I'm inclined to err on the side of "leave that up to users to do for themselves", at least for now.

@daniel-odrinski
Copy link
Author

Thanks for the detailed explanation @CKolkey. In that case, what would you recommend - the workaround above or something else that I should map in my configuration?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants