Sounds good! Thanks for the issue

I'd like to +1 on this general idea for a different use-case. In my specific case, I'd like to use tab to switch views: it's just way more intuitive to me to use tab rather than s. For my own use-case I can change the code and rebuild, but I'd prefer to be able to set this in the global config.

I took a look, but I also don't see an easy way of changing the built-in defaults for keybindings.

@dlvhdr If you agree that configurable overrides for default/built-in keybindings is a good idea, I'd be willing to submit a PR for this. I'd want to make sure we're on the same page as far as architecture/design before submitting a PR though - especially as this would result in additions to the config file.

This is definitely something I'm interested in.
My initial thoughts are around adding this to the config with default values like I've done for other options. I usually look at how lazy-git's config is structured for inspiration.
For example you can see the keybinding section here

I think this is where I set the default values

Gotcha - thanks. I think it's still valuable to keep the default config defined in the app but allow overriding of specific keybindings via the config file. This is consistent with the approach lazygit takes. Let me know if you disagree here.

I'd propose adding the following to the config file:

keybindings # already exists
  prs: [] # already exists
  universal: # new
    up: "up"
    upAlt1: "k"
    firstLine: "g"
    firstLineAlt1: "home"
    [ ... other keys omitted for clarity ...]
  pr:
    comment: "c"
    diff: "d"
    [ ... other keys omitted for clarity ...]
  issue:
    comment: "c"
    close: "x"
    [ ... other keys omitted for clarity ...]

I don't love the fact that this introduces a new key: keybindings.pr alongside the existing key: keybindings.prs, but I don't see a better solution unless we introduce a breaking change (e.g. moving keybindings.prs to keybindings.pr.custom_commands or similar) which I think is a bad idea for users.

Does this align with your expectations? Do you have another config in mind?

I don't yet have a super clear mental model of how to propagate the keybinding config into the app, but I think that will be clearer once I start working on the PR itself.

I think another approach that avoids breaking changes (which I also want to avoid) is to introduce a syntax like this:

keybindings # already exists
  universal: # new
    - key: up
      command: up
    - key: k
      command: upAlt1
    - key: g
      command: firstLine
    - key: home
      command: firstLineAlt1
  prs:
    - key: v # example for a custom keybind
      command: cd {{.RepoPath}} && code . # && gh pr checkout {{.PrNumber}}
    - key: c
      command: comment
    - key: d
      command: diff
  issues:
    - key: c
      command: comment
    - key: x
      command: close

If we're worried about conflicts with some bash alias or tool etc, we can add another key like builtin: up or something. Or prefix the command with dash up.

In principle, I like this more than my suggestion. However, I worry that it will be a little confusing to differentiate custom commands from builtins. In the example above, prs: [{key: d, command: diff}] is both a builtin and also a valid external command. How would we prevent users from re-mapping a builtin to a custom command?

I think this is what you are alluding to with:

If we're worried about conflicts with some bash alias or tool etc, we can add another key like builtin: up or something. Or prefix the command with dash up.

But I don't quite follow the suggestion here.

Yes exactly. I'm alluding to the confusion / conflict when a custom command like diff is also a builtin command.
My suggestion would be to make the config like this for example:

  prs:
    - key: v # example for a custom keybind
      command: cd {{.RepoPath}} && code . # && gh pr checkout {{.PrNumber}}
    - key: c
      command: dash comment
    - key: d
      command: dash diff

OR

  prs:
    - key: v # example for a custom keybind
      command: cd {{.RepoPath}} && code . # && gh pr checkout {{.PrNumber}}
    - key: c
      builtin: comment
      # or
      dash: comment
      # or
      dash-command: comment

Maybe you can think of a better name than builtin, as English isn't my native language.

Ah, right, glad we're on the same page. Thank you for the examples - that clarifies it for me.

I think command: dash comment is confusing because what if dash is a command on a user's machine. How would they (and gh-dash) disambiguate between the built-in function and the external command dash?

Maybe you can think of a better name than builtin, as English isn't my native language.

I can't come up with anything better than builtin so I think we should go with that.

Sounds good!

Is this up for grabs? I am open to giving it a try.

Yeah definitely @miniscruff!