Mac Git keyboard shortcut, i.e. ^+Shift+G to be CMD+Shift+G

[krstp]

It is great to see Git integration to be part of ZED! Thank you team for the wonderful work.

However, I would prefere if the keyboard shotcuts were more Mac centric as ZED is generally the Mac code editor. I would love to she CMD+G key combination instead of CTRL(^)+G key actions.

Thanks!

[gplusplus314]

I understand that not all developers are on macOS, and even those that are, may have dived into different depths of the platform. I made another discussion that touches on the differences between macOS keyboard shortcuts and all other operating systems. I went into detail with the idioms and expectations. While it isn't specifically about Git within Zed, it is about keyboard shortcuts in Zed. So, for anyone reading this, #27035 is also a relevant discussion that hopefully elucidates this problem a bit more.

[mikayla-maki]

The reason we didn't select cmd-shift-g is that it's already bound to [editor::SelectPrevious { "replace_newest": true }]

[gplusplus314]

Hey there. I took some time to put together some code pointers to hopefully help you, or anyone else working on Zed. I understand the reasoning, but it seems to contradict Zed's behavior on Linux, so I've compiled some examples. At the end, I TLDR a proposed long term solution.

The default binding on Linux for showing the Git panel is ctrl-shift-g, (link). Translating that to macOS idioms, it should be cmd-shift-g, but it's ctrl-shift-g (link), as the OP indicates. I go into detail about macOS keyboard idioms in #27035 , including differences between Zed's documentation and the unique Apple way of doing things.

In Linux, ["editor::SelectPrevious", { "replace_newest": true }] is bound to ctrl-k ctrl-shift-d (link). So in order for this to be translated to the macOS idioms, it should be cmd-k cmd-shift-d, but it's actually bound to cmd-k cmd-ctrl-d (link), which is another inconsistency.

The cmd-shift-g chord is bound to search::SelectPreviousMatch on macOS (link). Translating this from macOS to Linux should be ctrl-shift-g, but as shown above, that chord is for accessing the Git panel. So here is a contradiction.

Short term, users can easily just override the Git panel keybind in their own config, and that's likely good enough at this stage of development. Sorry @krstp - but feel free to disagree!

Long term, I would propose a unified keymap using placeholder modifiers, allowing the user to choose between all available modifiers. This is similar in concept to how Vim allows you to configure any arbitrary key as the leader key, or how the Kitty terminal allows you to configure kitty_mod arbitrarily. For example, a macOS config could configure kitty_mod to be cmd, whereas a Linux config could be configured to be ctrl, but then all keybinds are always identical across operating systems, properly translated for their appropriate idioms.

So imagine having a setting for zed_mod, if you will. That's the TLDR.

[krstp]

@mikayla-maki I see the point you are making, however, I would rather report it as possible BUG, not the existing functionality. Why a BUG? Because cmd+shift+g is valid when one searches first using cmd+f. As such, when given word or string sequence is provided in find input, the cmd+g/shift+cmd+g works really well yielding search next/previous instances. However, those keyboard shortcuts should not be active after user presses ESC after he/she is done with cmd+f. As soon as user esc-apes from the search, the shift+cmd+g combination should not remain active still referencing to find prompt.

I hope you see and understand what I am pointing to.

It would be still nice to have be able to reference cmd+shift+g to git functionality.

@gplusplus314 I see your point, but as you describe it is somewhat more of a preference; more of an accessibility issue for users with ergonomic needs ;) most of all it is a VIM layer on top of regular ZED mapping.

[krstp]

@mikayla-maki let me know if I should fill in the BUG...
@gplusplus314 I see your point of user defined keybinding; however I think it still hoovers under the BUG imho

[louwers]

This is really a bad design decision.