Macvim: It seems impossible to implement a <D-,> mapping.

[jordwalke]

It seems it is not possible to override the

[eirnym]

This shotcut is an Apple-guidelined standard to call preferences of an application. You can try to change this shotcut in System Preferences.app for MacVim and check if you can bind it.

[jpetrie]

Anything we explicitly set a key equivalent for in MainMenu.nib can't be bound (or really, recognized) by vim; we don't ever implement performKeyEquivalent: so we don't get notified of any keystrokes that are key equivalents.

Intercepting the equivalent would not be the right course of action as it would leave the menu UI in an incorrect state.

Probably the right thing for MacVim to do here is respond to D- mappings by setting the appropriate key equivalents for the appropriate actions, and clearing them when the mapping doesn't correspond. We could use macmap.vim as the basis for such a mapping, I suspect.

There's a few other bugs floating around that are essentially this same problem.

[chdiza]

There's a few other bugs floating around that are essentially this same problem.

I don't really think this is a problem. Cmd-, is the universal Mac shortcut for preferences, just like Cmd-H is for hiding a window. A select few things like this shouldn't be mappable from within Vim, IMHO.

[eirnym]

At least remapping default keybindings in System Preferences works for other apps so if a man really wants to shoot his leg, he can try it.

[jordwalke]

I would like to use command+, as a way to bring up preferences for MacVim, but bring up my own special config file which sets prefernces for MacVim. I would also like to be able to script this from VimScript (using menu commands or something else) so that I can share that same experience with other people without having to fork MacVim. The Apple design guides probably don't say anything about not preventing people from customizing this mapping in the app, do they?

It sounds like some people might be misinterpreting the feature request here to be that I wish to force people to map command+, to something other than the current MacVim settings. That is not the case.

There are also other issues as well that are related. For example, I cannot find a way to make MacVim's command+n/command+shift+n behavior match other popular editors such as VSCode. That is because the menus are not changeable until a window is open in the first place. So how are you supposed to change the key shortcut for the first window you open? This brings me to another good point. How would we allow customizing of key mappings when no vim script has yet run? There hasn't yet been an opportunity to even run the menu commands.

Both the command+, shortcut and command+n suffer from this problem. The command+, suffers dually because you cannot even change it after a vim window is open. Are these two separate issues that warrant two separate fixes? Maybe not.

[eirnym]

@jordwalke Have you tried to unset/redifine this particular menu item in System Preferences.app? The key bindings from the menu are handled by OS X Window System Server, not by app itself.

[eirnym]

From a MacVim perspective itself, this issue is kind-a won't fix as this key binding works well if you set a different key for a menu item.

[jpetrie]

The key bindings from the menu are handled by OS X Window System Server, not by app itself.

The key equivalents are all hard-coded in MainMenu.nib. The OS is not providing them for MacVim.

That is because the menus are not changeable until a window is open in the first place. So how are you supposed to change the key shortcut for the first window you open? This brings me to another good point. How would we allow customizing of key mappings when no vim script has yet run? There hasn't yet been an opportunity to even run the menu commands.

These are good points; I believe we don't have a vim process until at least one window is open, so we'd have to rely on the .nib defaults for the _very first_ run. Once MacVim's launched vim at least once, if we implement the scrape-and-map approach I suggested in my first comment, I guess we'd need to write the new key equivalents into defaults (where we store the other MacVim-specific preferences) in order to make them bind correctly on subsequent window-less launches.

That makes things more complicated. I don't generally like to encourage storing stuff in defaults since they don't travel with the user's .vimrc, et cetera, as well.

[eirnym]

The key equivalents are all hard-coded in MainMenu.nib. The OS is not providing them for MacVim.

Yes, and these keys are handled by Mac OS X. Replacing them to something else means breaking Apple Guidelines and it's not a thing which developers _should_ do.

Replacing or unsetting key combinations in System Preferences.app will solve your issue. you can set up an Apple Script to change these settings if you need an automated process.

[jpetrie]

We don't rigidly adhere to Apple's guidelines. Nor do Apple's own applications in places. When it makes sense for the needs or desires of our users, we ignore them, because users are more important. Legacy fullscreen is an excellent example of this.

Unless I gravely misunderstand, @jordwalke is not asking for us to _remove_ the default key equivalents. The request is for us to provide _a way_ for users to remove or remap them if needed. This seems entirely inline with the proposed workaround involving System Preference except that it is done within the purview of MacVim itself and thus doesn't require external solutions, so it is significantly more convenient for users who want to do this.

Further, unless I misunderstand what you are suggesting @eirnym, the System Preferences workaround cannot be used to _remove_ a key equivalent, only _replace_ one (I'm thinking you're referring to the Keyboard / Shortcuts / App Shortcuts UI, which lets you remap key equivalents based on exact menu text; is there some other place to do this?). I'm also unaware of how you can manipulate these settings via AppleScript as you suggest. An example AppleScript providing that feature might be enough to satisfy the needs of the users asking for this functionality, if you can provide it.

[eirnym]

• @jpetrie Yes, you're right, that System Preferences don't provide "remove a key sequence" functionality. Probably p-list hacking will do this good enough
• various AppleScript scripts could be found here, here, and here
• Also these preferences are stored in com.apple.universalaccess and in org.vim.MacVim:

    "com.apple.custommenu.apps" =     (
        "org.vim.MacVim"
    );

   NSUserKeyEquivalents =     {
        Preferences = "@,";
    };

[eirnym]

Also you can do this programmatically as in old-good-days (hehe) If you want.
Apple documentation

[eirnym]

BTW, very few progams provide functionality to modify keybindings for menu to the user.

[jordwalke]

Unless I gravely misunderstand, @jordwalke is not asking for us to remove the default key equivalents. The request is for us to provide a way for users to remove or remap them if needed.

Correct.

I want to create a vim configuration for people (a plugin) that will open their .vimrc when they hit command+,

[eirnym]

@jordwalke Would this plugin be MacVim-specific?

[jordwalke]

Probably not. I would likely map the same thing in Terminal Vim for this plugin.

[eirnym]

In my personal setup I wouldn't touch <D-,> keybinding as the Preferences dialog contains a few GUI- and host-specific options which don't belong to .vimrc file. I'd use something like <D-K> or <D-;> to distinguish MacVim-specific options and the rest.

Products from Jetbrains and Apple (Xcode as an example), and from other companies use this scheme to provide a different options which not fit to the global application options.

[jordwalke]

Editors I'm aware of that use command+comma to open text editor configuration:

• VSCode.
• Atom
• Sublime

This is not a radical proposal. It's becoming the _norm_.

I would remap <D-control-,> to be the rendering/GUI configs to allow access to the GUI menu (though it would be great if even that could be configured via vimrc).

[eirnym]

They have no additional preferences you can't setup in GUI. Otherwise it's normal, yes.

[eirnym]

Additionally I don't know what is your config about if there's :options already.

[jordwalke]

@eirnym Just imagine that I want to map <D-comma> to :options. This wouldn't change anything for anyone else. But when switching from other editors <D-comma> is the muscle memory for tweaking config so it probably makes sense to allow it as an optional mapping that people can customize. (It would be really overkill to have to fork the entire application just to be able to customize this one mapping)

[eirnym]

I've already listed various working ways to do achieve this without changing MacVim binary and with changing the code itself. If we really want to do it programatically, main menu file doesn't need to be changed, but we need to add a very specific handler to :an command to give ability only to change one single item (title and key binding).

Personally, I discorage going against Apple's Human Interface Guidelines and rebind this button inside some plugin. I prefer to have alternative keybinding like <D-.> or <D-k> by default and instructions how to use

[jordwalke]

Personally, I discorage going against Apple's Human Interface Guidelines and rebind this button inside some plugin.

What specifically goes against the HIG? (I'm just not aware of the particular recommendation).

[eirnym]

If it overrides preferences dialog and doesn't provide to change at least the same options as well, this looks more like hijaking for me.

If MacVim developers will provide :set options for every single preference, and Preferences menu item opens vimrc file, I'd probably use this way of reaching my $MYVIMRC file instead of executing a command everytime to open them.

[chdiza]

I'd probably use this way of reaching my $MYVIMRC file instead of executing a command everytime to open them.

Executing the command to do that is extremely simple, and can easily be given a mapping that is exactly as easy to type as

[eirnym]

I'd probably use this way of reaching my $MYVIMRC file instead of executing a command everytime to open them.

Executing the command to do that is extremely simple, and can easily be given a mapping that is exactly as easy to type as

Jetbrains products use <D-;>, for example

[jordwalke]

I'd probably use this way of reaching my $MYVIMRC file instead of executing a command everytime to open them.

Executing the command to do that is extremely simple, and can easily be given a mapping that is exactly as easy to type as

It's extremely simple to map from a keybinding that is not <D-,>. This feature request is the ability to map from <D-,>. One of the reasons why I would like that keybinding, is so that no matter which editor I am using, I can always use the same keybinding to edit my editor config (I have to jump around editors as part of my job).

[eirnym]

From vim perspective, it's fine if I open something like $VIMRC file, not :options or another plugin as most rc files are quite complicated to manage in fully programmatic way. Even :options doesn't write anything to it.

Although, MacVim has a few more settings which can't be set through $VIMRC file and I expect to open these options, but not editing vimrc. If these options is possible to set by using:set command, welcome to conflicting settings as vimrc processed every time you open a new MacVim window.

Only very few applications you have to restrart them to apply given options. And MacVim have options which could be applicable right now for every single window without any exception. Changing vimrc requires sourcing it in every single window. The VS Code is one of such applications you have to restart all the time you changing almost any setting.

Any vim-based plugin could run in MacVim won't apply all options to all its' GUI windows running at the time. This is a nature of Vim and MacVim: you can edit settings only in the running instance and those instances doesn't communicate with each other. Please, tell me if I wrong here, but it was one of the point to create NeoVim.

Therefore, I prefer to have a different key combination as it's done in Jetbrains products. There you have global settings and project-specific settings. In IntelliJ Idea, as an example, "one project" means "one window" and you can edit global setting which would affect every single window instantly after applying them or you can edit project-related settings which would applied only to the given project/window.

If we speak about "something easily to type like <D-,>" there're planty of keys we can use: <D-.>, <D-;>, <D-k>, etc.

[eirnym]

I'd probably use this way of reaching my $MYVIMRC file instead of executing a command everytime to open them.

Executing the command to do that is extremely simple, and can easily be given a mapping that is exactly as easy to type as

It's extremely simple to map from a keybinding that is not <D-,>. This feature request is the ability to map from <D-,>. One of the reasons why I would like that keybinding, is so that no matter which editor I am using, I can always use the same keybinding to edit my editor config (I have to jump around editors as part of my job).

In macOS you can define any key combination to any menu Item in any application. The methods are common and well-known. After you define anything else for Preferences, you can use it as a keybinding in MacVim.

[chdiza]

It's extremely simple to map from a keybinding that is not

@jordwalke Yes, I know; my comment was directed towards @eirnym, who seemed to be suggesting that opening $VIMRC is not sufficiently easy.

[jpetrie]

This discussion seems like it's going in circles at this point.

I just want to point out that from my perspective (as a maintainer) that I think this is a reasonable request and that a reasonably-implemented PR providing the capability to remap the chords that happen to be defined in MainMenu.nib would get consideration from me, at least.

For reference, "reasonably implemented" means that it

• does not change the current default behavior of vanilla MacVim (so those users who do not want this capability are not affected by its presence)
• does not leave the menu bar in an inconsistent state (so that remapping any chord removes the corresponding key equivalent from the main menu).

I would strongly suggest anybody implementing this feature also look at macmap.vim, because that file implies that this _used_ to be possible (back in 2006 at least), and if this feature gets implemented and that file is still getting sourced by the vim runtime it may have adverse affects on my first requirement above.