Fix bad interaction with never opening window + terminate on last window #1260
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Previously, if you configure MacVim to never open an untitled window on launch, *and* terminate MacVim on last window closing, you could get an odd behavior where MacVim will close itself soon after launch, usually when you fiddle with "About MacVim" or the preference pane. This isn't too big a deal but could potentially make it hard to change the preference back, and it's hard to know if a future macOS update will further break this behavior causing MacVim to keep terminating itself on launch (the termination behavior relies on the `applicationShouldTerminateAfterLastWindowClosed` API which is controlled by the OS). To fix this, simply make it so that the preference pane doesn't allow both settings to be set at once. If the user is trying to do so, set the other setting to be something sane. Also, in the `applicationShouldTerminateAfterLastWindowClosed` behavior, make sure we add additional protection so that it will not return true when we are set to never open untitled window (this should only be the case if the user manually set it using `defaults` because we are now already protecting against this in the preference pane logic). This should be fine because these two setting don't really make sense for the user anyway. It doesn't seem to make a lot of sense for the user to want this behavior. Note that I'm doing manual checking in preference UI instead of using some sort of key-value listening of NSUserDefaults because I'm afraid of some unintentional infinite recursion going on where the settings keep setting each other back and forth. By only doing this at preference pane changes this should not happen. Fix macvim-dev#1257
eirnym
approved these changes
Aug 4, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Previously, if you configure MacVim to never open an untitled window on launch, and terminate MacVim on last window closing, you could get an odd behavior where MacVim will close itself soon after launch, usually when you fiddle with "About MacVim" or the preference pane. This isn't too big a deal but could potentially make it hard to change the preference back, and it's hard to know if a future macOS update will further break this behavior causing MacVim to keep terminating itself on launch (the termination behavior relies on the
applicationShouldTerminateAfterLastWindowClosedAPI which is controlled by the OS).To fix this, simply make it so that the preference pane doesn't allow both settings to be set at once. If the user is trying to do so, set the other setting to be something sane. Also, in the
applicationShouldTerminateAfterLastWindowClosedbehavior, make sure we add additional protection so that it will not return true when we are set to never open untitled window (this should only be the case if the user manually set it usingdefaultsbecause we are now already protecting against this in the preference pane logic). This should be fine because these two setting don't really make sense for the user anyway. It doesn't seem to make a lot of sense for the user to want this behavior.Note that I'm doing manual checking in preference UI instead of using some sort of key-value listening of NSUserDefaults because I'm afraid of some unintentional infinite recursion going on where the settings keep setting each other back and forth. By only doing this at preference pane changes this should not happen.
Fix #1257