Add neovide_confirm_quit option to confirm before quitting

[viviicat]

This adds a new option, g:neovide_confirm_quit (default: 0), which, when set to 1 or v:true, will execute confirm qa instead of qa! when the window is closed.

Mostly fixes #874, by reducing the potential to lose work. It does not pop up a nice dialog box, of course. This is pretty much the way that nvim-qt does things.

Tested on Linux.

Please let me know if there's a more elegant way to query the option than putting it in an inline script.

What kind of change does this PR introduce?

• Feature

Did this PR introduce a breaking change?

• No, the option is disabled by default.

[Shatur]

I would enable it by default.

[ttytm]

@viviicat awesome 💪🙏

[viviicat]

@Shatur personally I like the idea of it being on by default, but since that would change default behavior I think it would be up to the project owner(s).

[ernie]

This does not seem to work on MacOS 12.3, neither via command-q or via clicking the menu option.

[dineshKumar777]

This does not seem to work on MacOS 12.3, neither via command-q or via clicking the menu option.

Just confirming. By default this option is disabled. Did you enable it by using g:neovide_confirm_quit=1??

[ernie]

Just confirming. By default this option is disabled. Did you enable it by using g:neovide_confirm_quit=1??

I tried both g:neovide_confirm_quit=1 and g:neovide_confirm_quit=v:true with no luck.

[ttytm]

Just confirming. By default this option is disabled. Did you enable it by using g:neovide_confirm_quit=1??

I tried both g:neovide_confirm_quit=1 and g:neovide_confirm_quit=v:true with no luck.

To be safe i'll ask this dump question. Did you build it again from source after the commit containing this functionality was merged?

[ernie]

To be safe i'll ask this dump question. Did you build it again from source after the commit containing this functionality was merged?

Not a dumb question at all! I'm a new user (only found Neovide last week), so I've only ever built the app since after it was merged.

[ttytm]

Okay nice.

A further step i would try is to enable it for the active session by entering the vim command :let g:neovide_confirm_quit=1 then check if there is a confirmation request when trying to close a session with modified, unsaved files

[ernie]

Okay nice.

A further step i would try is to enable it for the active session by entering the vim command :let g:neovide_confirm_quit=1 then check if there is a confirmation request when trying to close a session with modified, unsaved files

Appreciate the suggestion. I'd already tried that, but just to verify, tried again. Still closes without a prompt.

[viviicat]

Oh, another question: Do you have a modified buffer open? It won't ask to confirm if nothing requires saving. (It should prompt with anything as simple as typing gibberish into the default buffer)

Also, what happens if you just try to manually run :confirm qa?

[ernie]

Oh, another question: Do you have a modified buffer open? It won't ask to confirm if nothing requires saving. (It should prompt with anything as simple as typing gibberish into the default buffer)

Good question, and yes! I even used the ui_commands.rs file from your screenshot during my verification efforts. :D

Also, what happens if you just try to manually run :confirm qa?

That works as expected.

[viviicat]

I guess the event is being bypassed, then.

[dineshKumar777]

@ernie we are not able to reproduce your issue in both windows and mac os. Can you try again with latest neovide.
2020 m1 macbook pro - macOS monterey 12.2.1

if issue still persists with latest version, it would be helpful if you share a screen recording.

2022-04-16_16-57-15.1.mp4

[ttytm]

Also ZQ which is equivalent to :q! will not triggering it btw.

"OS"-window closing should trigger it.

[ernie]

Also ZQ which is alias for :q! will not triggering it btw.

"OS"-window closing should trigger it.

Aha! So, Command-Q didn't trigger it. Only clicking the close button in the top left. That explains it, as I never quit Mac apps using the X

I was able to get it "working" by clicking the X.

Neither Command-Q nor selecting neovide -> quit neovide worked.

[ttytm]

Yes, this is not saying one must use the X. Command Q should do the thing. I'm not having access to a mac right now. Maybe the fellow thread readers can give some more input.

[ernie]

I ran with —log to see if an event was seen before quitting. The only time I saw the CloseRequested event was when clicking the X. Upon command-q the key press wasn’t reflected anywhere, the log just ceased.

[ttytm]

@ernie we are not able to reproduce your issue in both windows and mac os. Can you try again with latest neovide. 2020 m1 macbook pro - macOS monterey 12.2.1

if issue still persists with latest version, it would be helpful if you share a screen recording.

2022-04-16_16-57-15.1.mp4

This is off topic but this is a wonderful job on desktop customization in this little preview. Didn't knew it's possible to go on Mac that far. Could provide a link or recommend a resource?

[dineshKumar777]

I ran with —log to see if an event was seen before quitting. The only time I saw the CloseRequested event was when clicking the X. Upon command-q the key press wasn’t reflected anywhere, the log just ceased.

@ernie Thanks for the feedback. good thing we are progressing on finding the root cause.
FYI, in windows I tried with ALT+ F4, and this works as intended. Seems like mac specific issue. Will create a separate bug to track this issue.
More info on this rust-windowing/winit#41

This is off topic but this is a wonderful job on desktop customization in this little preview. Didn't knew it's possible to go on Mac that far. Could provide a link or recommend a resource?

@tobealive I never used Mac device so far :( . This is verified and shared in neovide discord channel by another community member. You can join in if you are interested.

[technicalpickles]

Since the last comment, rust-windowing/winit#41 was closed by rust-windowing/winit#1583 . It looks like we are using the fork at neovide/winit on the new-keyboard-all branch. It doesn't look like the commits in that tree are upstream though.

[MultisampledNight]

Yes, and we'll have to wait until we can use upstream's new-keyboard branch, because merging in every single upstream change is not really viable.