Support fixing "menu not found" error when started through mvim with default menus disabled. #1231
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.
While investigating issue #1230, I added
let did_install_default_menus = 1
to my.vimrc
. This disables the generation of Vim's default menus, pergui.txt
. It also causes an error to be generated when usingmvim
to start MacVim from the Terminal:When
did_install_default_menus
is used this way,menu.vim
's calls tomacmenu
fail to find any menus, since they were never generated. This change introduces a similar global variable,did_install_default_mac_menus
that can be set similarly to skip themacmenu
calls and avoid the errors. This more easily supports the use-case where somebody wants to completely redefine the menu structure, which isn't common, but is what led me down this rabbit hole in the first place.I considered a few other approaches. They all have pros and cons, this seemed like the simplest overall:
menu.vim
aggressively setsdid_install_default_menus
to make the script reentrant. We could set the variable after all themacmenu
commands finish, letting one variable control both. However, this would make managing upstream merges harder, especially if anything now or in the future causes the script to return early.macmenu
could be changed, adding!
support, so thatmacmenu!
would silently ignore missing menus. This would probably introduce more upstream merge challenges, and wouldn't support the "I'd like to completely skip generating these menus" scenario.I explicitly did not update
delmenu.vim
to reset the new variable. It would be more correct to do so, but would create an upstream merge conflict for no appreciable benefit: ifmenu.vim
is resourced at runtime,macmenu
has no effect anyway. That could be fixed, but that's a much bigger change.This is a fairly niche change, so I'm entirely convinced it's worth pulling in, but I did the work so I figured I'd see what folks thought.