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

MacVim closes when bringing up the "About MacVim" window when there are no other windows open #1257

Closed
1 of 7 tasks
jwanja opened this issue Jul 28, 2022 · 7 comments · Fixed by #1260
Closed
1 of 7 tasks
Milestone

Comments

@jwanja
Copy link

jwanja commented Jul 28, 2022

Steps to reproduce

  1. Open MacVim with no windows (see Note below)
  2. Navigate to and click the "About MacVim" menu item in the menu bar
  3. The about MacVim window flashes and then disappears

I have a hunch that the issue is from the combination of these two options:

  1. Open untitled window === "never"
  2. After last window closes === "Quit MacVim"

If I open a blank window or change the "After last window closes" option to "Keep MacVim Running", the About MacVIm window will stay open.

Expected behaviour

Be able to view the "About MacVim" window at any time and with any settings configuration.

Version of Vim and architecture

9.0.65

Environment

Monterey 12.4
iTerm 2
"xterm-256color"

How MacVim was installed

GitHub

Logs and stack traces

No response

Vim configuration where issue is reproducable

No response

Issue has been tested with given configuration

  • by running MacVim.app from GUI macOS interface
  • by running vim/gvim/etc installed by MacVim
  • by running other versions of vim (e.g. /usr/bin/vim)

Issue has been tested with no configuration

  • by running mvim --clean (or gvim, supplied by MacVim distribution)
  • by running vim --clean (in terminal, supplied by MacVim distribution)
  • by running vim --clean (in terminal, other suppliers, e.g. /usr/bin/vim)

Other conditions

  • The both Homebrew packages "vim" and "macvim" are installed
@jwanja
Copy link
Author

jwanja commented Jul 28, 2022

Also I just realized if I press any menu bar item, e.g "MacVim", "File", "Edit", etc., and then press the menu bar item again, the application will close.

@ychin
Copy link
Member

ychin commented Jul 29, 2022

Oh that’s interesting. Does seem like a bug.

Just out of curiosity though why would you have those two options? It seems somewhat contradictory and I’m curious why someone would configure MacVim that way.

@eirnym
Copy link
Contributor

eirnym commented Jul 29, 2022

I've tested with the latest MacVim 9.0.65 (173) on Catalina.

  1. I set the options below and reload MacVim
    • Open untitled window === "never"
    • After last window closes === "Quit MacVim"
  2. I opened MacVim and opened preferences window, closed it without changes and MacVim exited which agree with my understanding of "Quit after last window closes"
  3. I opened MacVim and opened about window, closed it without changes and MacVim exited which agree with my understanding of "Quit after last window closes"
  4. I opened settings and new editor window. Closing one of windows doesn't quit the app, which agree with my understanding of "Quit after last window closes"

Could you please explain me, where is the contradiction?

@jwanja
Copy link
Author

jwanja commented Jul 29, 2022

@ychin it 100% is contradictory to have the settings configured the way I did. I've already changed those options to something sane, but I couldn't help but investigate what was happening when the About screen disappeared immediately when I opened it up.

I have a unique use case since I'm using MacVim as a proxy to have a reliably updated vim executable since my company blocked homebrew on our machines. For the most part I'm using vim in a terminal and have aliased it to point to MacVim's instance of vim. I really only open the GUI when I need to open a large file to search around in faster than TextEdit, or when I feel like it has been a while since I've updated MacVim and more importantly updated the vim version.

@jwanja
Copy link
Author

jwanja commented Jul 29, 2022

I've tested with the latest MacVim 9.0.65 (173) on Catalina.

  1. I set the options below and reload MacVim

    • Open untitled window === "never"
    • After last window closes === "Quit MacVim"
  2. I opened MacVim and opened preferences window, closed it without changes and MacVim exited which agree with my understanding of "Quit after last window closes"

  3. I opened MacVim and opened about window, closed it without changes and MacVim exited which agree with my understanding of "Quit after last window closes"

  4. I opened settings and new editor window. Closing one of windows doesn't quit the app, which agree with my understanding of "Quit after last window closes"

Could you please explain me, where is the contradiction?

@eirnym for me, step 3 has a different behavior. When I choose the option to open the About MacVim window, if it will be the only window owned by MacVim, it flashes on screen very quickly, then automatically closes itself, and then MacVim exits.

@eirnym
Copy link
Contributor

eirnym commented Jul 29, 2022

I observe the flash, but it's not doing every time I close MacVim and I can't consistently say, that this is any kind of a ghost window or not.

Additionally, I observe similar flashing when closing Terminal.app, Preview.app and few others I've just tested when I close the app which has no open windows left. This flash is not quite visible when there's no opened browser with 100 tabs spread to few windows opened. I believe the opening and the closing animations are played independently if there're any opened windows or not.

Could you try to disable or minimize closing macOS animations by using ui tweaks or changing defaults?

@ychin ychin added this to the snapshot-174 milestone Aug 4, 2022
@ychin
Copy link
Member

ychin commented Aug 4, 2022

This setting is done by using the applicationShouldTerminateAfterLastWindowClosed API. It's kind of up to macOS when it calls it and when it feels like closing the application, so maybe it depends on different conditions.

I think I will just make it clear that the options of "Open untitled window === never" and "After last window closes === Quit MacVim" cannot be set together. Maybe add some preference pane logic to make it so as well, and/or enforcing this mutual exclusion in the code. It just doesn't make sense to have them set together, as by definition macOS should immediately close the app. In fact I wonder if in a future version of macOS, having those options set together would cause MacVim to keep closing itself causing the user to never be able to change the setting in the preference pane which would be bad, so this should be fixed (the user can obviously still use the terminal to set it using defaults, but that's not ideal).

ychin added a commit to ychin/macvim that referenced this issue Aug 4, 2022
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
ychin added a commit that referenced this issue Sep 15, 2022
Updated to Vim 9.0.472.

Announcements
====================

Sponsors
--------------------

MacVim now allows you to sponsor the team! Any amount would be
appreciated and it is of course optional. See the announcement (#1271)
for more details.

Supporting old versions of macOS (10.12 or below)
--------------------

Currently, macOS supports macOS 10.9 or above. However, this is getting
harder to do so as time goes on (e.g. the latest Xcode doesn't support
building for it). In the near future, MacVim will mostly target 10.13
(High Sierra) or above, with 10.9 - 10.12 as legacy support. Visit this
discussion (#1288) if you would be affected and would like to know more.

Features
====================

Resizing MacVim new options
--------------------

You can now smoothly drag and resize MacVim without having it
constrained to fixed multiples of the text size, by setting the
"Smoothly resizes window" under General preference pane. This also
allows MacVim to behave better when used with third-party tools (e.g.
BetterSnapTool) to snap it to one side of the screen. #1276

The command line can now be pinned to the bottom of the window with a
setting (under Appearance preference pane). This makes it look better
aligned when using smooth resizing, or in other situations where the
window size is not a direct multiples of Vim's text size (e.g. full
screen or guioption+=k). #1280

New supported text styles
--------------------

Vim highlight groups `strikethrough`, `underdouble`, `underdotted`,
`underdashed` are now supported. #1287

New Vim features
--------------------

Virtual text allows you to place custom texts to be displayed inline for
diagnostic information and more (e.g. build errors, CSS color preview).
See `:help virtual-text` for more information.

The default color schemes (e.g. desert) are now fixed to look correct
again.

Misc options and commands:
- `set nosplitscroll` lets you preserve the windows' scroll positions
  when splitting. (v9.0.0445)
- `:defer` allows you to clean up in a function. (v9.0.0370)
- `:echowindow` allows you to echo a message to a floating popup message
  window instead of to the command line. (v9.0.0321)

Fixes
====================

- Fixed non-native full screen not working well with the notch on newer
  MacBook's when set to not show menu bar. You can also use
  `MMNonNativeFullScreenSafeAreaBehavior` to force MacVim to use the
  notch area as well if you don't mind some content being obscured. #1261
- Fixed bad interaction when two settings ("Open untitled window: never"
  and "After last window closes: Quit MacVim") are set together. #1257
- Fixed the bundled Vim tutor not working when launching from the Help
  menu #1265.
- Fix crashing on launch under macOS 10.9. #1212
- Fixed potential crash when switching appearance mode in MacVim
  preferences. #1270
- Korean localized menus no longer throw a syntax error on launch. #1278
- `did_install_default_menus` should work in MacVim now. #1267

General
====================

Sparkle (updater for MacVim) is now updated to 1.27.1 (#1284), and we no
longer use DSA keys for signing updates (#1285) as we are using EdDSA
already.

Scripting
====================

- Scripting languages versions:
    - Python is now built against 3.10, up from 3.9.

Compatibility
====================

Requires macOS 10.9 or above.

Script interfaces have compatibility with these versions:

- Lua 5.4
- Perl 5.18
- Python2 2.7
- Python3 3.10
- Ruby 3.1
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

Successfully merging a pull request may close this issue.

3 participants