"<<Close All -unlocalized>>" intermittently replaces "Close" in the File menu when holding the Option key

[jpetrie]

Steps to reproduce

Launch MacVim 8.2.3455 (172).
Press and hold the option key and use the mouse to open the File menu. Repeat this several times, with a half-second or so delay. Observe the "Close" / "Close All" menu items.
Eventually, often by the third or fourth try, "Close All" will become "<<Close All -unlocalized>>"

menu.vim doesn't define a "Close All" item or corresponding :macmenu, it appears that Cocoa inserts this alternate item to the item with the performClose: selector. In fact, doing aunmenu * in gvimrc and then rebuilding a File menu with any item associated with performClose: via macmenu will exhibit this behavior.

Searching the internet reveals that other applications have experienced this.

Doing let do_no_lazyload_menus = 1 in vimrc (as the very first line, before executing anything that causes menu.vim to get sourced) seems to make the problem much harder to reproduce, even though nothing in menu.vim directly affected by the variable seems obviously related. Specifically, it seems to take opening a separate window in MacVim to trigger the menu changing.

Expected behaviour

"Close All" should remain "Close All" not display what appears to be diagnostics text.

Version of Vim and architecture

MacVim 8.2.3455 (172)

Environment

macOS Monterey 12.1 on a MacBook Pro (14-inch, 2021) (M1 Max).

How MacVim was installed

Downloaded from GitHub releases page (using the .dmg).

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

[jpetrie]

I've also noted, running this in a debugger attached to a local build, that whatever this phantom "close all" menu item is doing, it only triggers one actual "schedule close" message to a MMVimController. The rest of them get closed via their connections dropping. I'm not sure if this is good or bad or irrelevant.

[eirnym]

Hmm… with Polish localisation (system default) it works fine (in most cases) :)

Tried locales en_US, de_DE, hu_HU and few others. issue is reproduced, sometimes with Polish fallback.

[jpetrie]

Curious - when you get the behavior in a non-English locale, does it say "unlocalized" in English or is it saying whatever the correct word for "unlocalized" is in that locale?

My instinct is that it's somehow related to the fact that the inserted "Close All" item has no entry in any of the localizable string tables, and the text we're seeing is a result of Cocoa saying "hey, this string isn't localizable." But it's Cocoa that appears to be inserting the item, so I'd expect there would be a translation available for it provided by Apple.

[eirnym]

In most cases it says "Zamknij wszystkie" with the same shortcut.

Ps: no configs were altered. Tested with $ LANG=en_US.UTF8 vim where vim is alias to MacVim GUI

[ychin]

What to hear something funny? I tested this in Finder as well (you have to open a Finder window with no tabs), but couldn't see this on other native apps like Preview. Screenshot below:

I would imagine this is a macOS bug…

I'm kind of curious about what you said in #1230 (comment) though, regarding the "Close All" behavior. I may just take a look to see if it makes sense at all. From testing it with unsaved files it properly show the dialog box in each window so I think it's working fine.

[ychin]

Honestly though I kind of dislike how "Close" is mapped to performClose:. I think it's to make sure dialog boxes and preference pane can still be closed with Cmd-W, and apparently is how most macOS apps do it, so I guess it works.

[ychin]

@jpetrie / @eirnym I'm wondering if you two see this too (<<Close All - unlocalized>> on Finder)? If so, I'll probably just close this. It seems like a macOS bug.

[eirnym]

@ychin I observe it on Catalina and don't observe this behaviour in Monterey (macOS 12,5).

I still believe it's an internal macOS issue rather than poor menu handling in MacVim.

MacVim creates menu items, but not visual elements themselves.

[jpetrie]

I don’t see it in Finder on 12.5, but I do agree it’s probably not something MacVim can solve - it doesn’t seem to be related to how we configure the menu binding for close, but how macOS adds the special casing for that item.

[ychin]

I think I will close this issue. From MacVim's perspective, there is no reason why "File.Close" is different from "File.Save" for example, and I'm seeing in Finder as well. When I was playing around with it, I somehow also got the bug to go away in my local build (just by removing and adding the menu item and naming it different things). This seems like macOS has some internal bug where it's improperly handling this menu item, sometimes.

Filed a feedback to Apple so hopefully they will look at it.