Better UX

[jesseduffield]

Topic Lazygit's UX could be improved quite a bit. This discussion is here for the sake of coming up with some UX changes that will make lives easier for Lazygit's users. I mostly want to focus on keybindings. The end-result of this discussion will be a new release of lazygit that revamps the keybindings and gives the users a popup saying 'some things have changed!'.

Suffice it to say that for some of the bigger changes where people have build up muscle memory, we should make it easy enough to revert to the old keybindings (even if that just means pointing them to a doc that gives them a chunk of yaml to chuck in their config).

I have two goals, which sometimes conflict with eachother. I want Lazygit to be easy to use for newcomers, and I want Lazygit to be fast to use for long-term users. I've decided that if we aren't sure whether to add a confirmation panel for something, we should add it. Long-term users will develop the muscle memory to hit 'enter' after the original keybinding so it won't slow them down. We can also allow configuration which removes confirmation panels for things a user might regularly do.

Your thoughts

I'm going to phrase this as a proposal but I want to get other people's thoughts before committing. to anything. If you disagree with any of the following, or can think of a better approach, please say so! If you have something similar that you think could be improved, this is a good place to discuss it.

Left/Right keys

When I first made lazygit, the gocui package depended on termbox which didn't support using shift+tab, so I decided to use the left/right keys to navigate side panels. I've since extended that pattern to other places e.g. the staging panel where left/right flicks you through hunks. Although using left/right is nice in that you don't need to hold down a modifier key, it means we can't use those same keys in contexts where they would make more sense. If we commit to using tab/shift-tab to iterate through things vertically, we can use left/right to introduce vscode-like keybindings for interacting with the file tree, i.e. the left key will collapse the folder, and pressing it again will take you up to the parent folder. Currently we use enter to toggle whether a directory is open and that's not entirely intuitive.

Global keybindings

No global keybindings should have context-specific overrides. E.g. if 'R' means refresh globally, no panel is allowed to define its own 'R' keybinding (at the moment it will have you reword a commit in the editor without any confirmation panel). Some exceptions can apply if we still provide the option to do the global thing in a menu e.g. pressing 'P' when you've selected a tag should ask you if you want to do a regular 'push' or just push that tag.

Removing items

Any place we use 'd' to remove an item, we should also be able to use 'backspace' and 'delete'.

Selecting a range of items

We need a standardised and intuitive way to: 1) select a range 2) select multiple things

Currently in the staging panel you can press 'v' to select a range of lines, and then when you press space it stages those lines. In the commits panel you can press 'c' to pre-select a commit to be cherry-picked, and if you press shift+c it will pre-select from the last pre-selected commit to the current one. Unlike with the staging panel, we have a use case to select multiple things, perhaps with gaps inbetween, ahead of time. At any rate, we should standardise this. I'm not actually sure what makes the most sense, but whatever it is will need to work with the file tree where we'll be using the same pattern for bulk file actions

Menu-specific keybindings

I often need to hard-reset onto a commit and I don't like having to press 'g' then down twice, then enter. That's four keypresses for something pretty trivial. Reordering those menu items is out of the question given the damage it can do, but what would be great is to be able to specify keybindings for each menu item e.g. 's' for soft reset, 'm' for mixed reset, and 'h' for hard reset. That way I just press 'gh' and I'm done.

An alternative is to do something like vim where you type your keys ahead of time and then something happens, but I am not a big fan of that approach just because I don't find it user-friendly and we can have just as few keypresses taking the menu-based approach that tells users what they're doing as they do it.

More confirmation panels

Pressing enter doesn't take that long, especially if it's in your muscle memory. We should have a confirmation panel for anything that can get you into a state that's hard to reverse or escape from. This includes the keybinding for rewording a commit in your editor.

Should we include confirmation panels if you've selected an item in a menu? I'm not so sure. That's going to be less accident-prone compared to pressing a random key outside a menu.

Multiline prompts

The only multi-line prompt right now is the commit message panel. We need to decide on one of the following: 1) enter key always submits, alt-enter (or ctrl-enter) adds newline in multiline prompt 2) enter submits in single-line prompt, alt-enter (or ctrl-enter) submits in multiline prompt (and enter adds a newline) 3) something else

Whichever we go with, we should make it clear to the user which keys do what. Although we currently have the available keys shown in the options view at the bottom of the screen, it's not very obvious. I'd like t see a view sitting underneath the prompt view that tells the user what the important keybindings are.

[jesseduffield]

tagging some people who might have thoughts around this stuff @peppy @mjarkk @Ryooooooga @sdegutis @birgersp @dawidd6 @glvr182 @jbrains @MikaelElkiaer @OliverJAsh @fsmiamoto @fluffynuts

[peppy]

I have two goals, which sometimes conflict with eachother. I want Lazygit to be easy to use for newcomers, and I want Lazygit to be fast to use for long-term users. I've decided that if we aren't sure whether to add a confirmation panel for something, we should add it. Long-term users will develop the muscle memory to hit 'enter' after the original keybinding so it won't slow them down. We can also allow configuration which removes confirmation panels for things a user might regularly do.

I will say that I've introduced basically everyone I know to lazygit, of varying skill levels and... ability to accept new things (some who were 100% gui client previously) and no one has outright rejected lazygit due to it being hard to new users, in fact everyone is still using it to date. So I think it's already in a pretty good place.

Left/Right keys

I switch between panels a lot. I used to use number keys but generally find it faster to left/right these days. I have this bound to H/L to match vim style navigation.

For new users I'd agree with tab/shift-tab. And also allowing folder expansion using arrow keys, as that is what a user would expect.

Global keybindings

No global keybindings should have context-specific overrides. E.g. if 'R' means refresh globally, no panel is allowed to define its own 'R' keybinding (at the moment it will have you reword a commit in the editor without any confirmation panel). Some exceptions can apply if we still provide the option to do the global thing in a menu e.g. pressing 'P' when you've selected a tag should ask you if you want to do a regular 'push' or just push that tag.

Makes sense. I don't think I use any overlapping bindings.

Removing items

Any place we use 'd' to remove an item, we should also be able to use 'backspace' and 'delete'.

I'd still use 'd', but the defaults you propose sound better.

Selecting a range of items

Currently in the staging panel you can press 'v' to select a range of lines, and then when you press space it stages those lines. In the commits panel you can press 'c' to pre-select a commit to be cherry-picked, and if you press shift+c it will pre-select from the last pre-selected commit to the current one. Unlike with the staging panel, we have a use case to select multiple things, perhaps with gaps inbetween, ahead of time. At any rate, we should standardise this. I'm not actually sure what makes the most sense, but whatever it is will need to work with the file tree where we'll be using the same pattern for bulk file actions

My first thought as a user would be that space selects items/lines and enter actions on them.

Menu-specific keybindings

I often need to hard-reset onto a commit and I don't like having to press 'g' then down twice, then enter. That's four keypresses for something pretty trivial. Reordering those menu items is out of the question given the damage it can do, but what would be great is to be able to specify keybindings for each menu item e.g. 's' for soft reset, 'm' for mixed reset, and 'h' for hard reset. That way I just press 'gh' and I'm done.

Sounds cool. Would be nice if the shortcut letter highlighted in the dialog option similar to underlined shortcuts in OS menus.

More confirmation panels

Pressing enter doesn't take that long, especially if it's in your muscle memory. We should have a confirmation panel for anything that can get you into a state that's hard to reverse or escape from. This includes the keybinding for rewording a commit in your editor.

It's very rare I do something I didn't mean to, so I'd likely turn these off. And even if I do, reflog is always there.

Should we include confirmation panels if you've selected an item in a menu? I'm not so sure. That's going to be less accident-prone compared to pressing a random key outside a menu.

I think the menu itself is enough.

Multiline prompts

The only multi-line prompt right now is the commit message panel. We need to decide on one of the following:

1. enter key always submits, alt-enter (or ctrl-enter) adds newline in multiline prompt
2. enter submits in single-line prompt, alt-enter (or ctrl-enter) submits in multiline prompt (and enter adds a newline)
3. something else

I always use external editors for anything multiline, so can't comment on this. I don't think the built-in editor will be something I ever use, because

• It doesn't act like vim so navigating back to make edits is hard
• Pasting into it could potentially exit the commit edit dialog and start sending rogue keypresses getting a repo into a very very bad state.

And that second point if probably the most distressing thing I've found in lazygit to date. I've done this two or three times, accidentally pasting multiline into a single line editor popup, or just hitting cmd-v while lazygit is focused. Not sure if there's a way around this (maybe stop accepting shortcut keys if they are invoked faster than you'd expect from an interactive user) but it is something to consider.

[thesoftwarephilosopher]

Haven't read this yet, but responding to the not-said-to-be-addressed-here issues in #1708's last comment in here so it's all in one place:

Thanks for the detailed feedback. I would say that based on your feedback you actually are fairly representative. I'm going to make a new issue about improving the UX #1712 and I'll add a few things that you mentioned.

👍

I just tried to select multiple files with Shift-Up/Down in Files panel to act on them with space/delete.

• My understanding was that terminals don't support shift up/down. If they do we should do that (although we don't currently support selecting a range of files)

Makes sense, I'm not used to using terminal-based apps anymore. I'm using Windows Terminal so alt-[etc] may not work very well. I remember Apple Terminal has a setting to allow alt-[etc] to be passed through as meta key to terminal apps and I can't find that anywhere here. (It probably is here, I just haven't looked super hard.)

I still don't know how to get rid of only non-ignored untracked files without nuking node_modules/etc also.

• does git clean -fd suffice?

I don't know, it's been 10 years since I looked at what that command does and avoided using it since I was confused about it at the time. Does it get rid of gitignored files/dirs too?

When done with staging, I thought Tab/Shift-Tab would get me back to Files.

• I feel like escape still makes sense here. I want to use tab/shift+tab for moving through things vertically (e.g. moving through hunks in the staging panel: currently done via left/right).

🤷 The movement between panels overall is confusing to me. I think I get your idea that Enter is diving into a sub-panel and Escape is escaping/jumping-out of it. But I intuitively I looked at it entirely spatially, and tried to move around panels directionally.

Took me a while to realize red commits meant unpushed.

• I've had this feedback before. Not sure how to make this more apparent without having some kind of walkthrough thing at the beginning. We could use a different colour, given that red is typically associated with a problem, but I like the analogy to red/yellow/green traffic lights.

Red means stop in that analogy, and unpushed commits don't quick make sense as "stop" to me. Mainly because I don't auto-map pushed/unpushed to movement or lack of movement mentally. Maybe it makes sense from a network-traffic point of view. But I didn't get that until you brought it up and I thought about it a bit just now.

Looked for multi-line commit option, can't find it --- assuming it's just not there.

• pressing alt-enter will add a new line.

I think I tried this and it didn't work. But see above about Windows Terminal.

[thesoftwarephilosopher]

Lazygit's UX could be improved quite a bit. This discussion is here for the sake of coming up with some UX changes that will make lives easier for Lazygit's users. I mostly want to focus on keybindings. The end-result of this discussion will be a new release of lazygit that revamps the keybindings and gives the users a popup saying 'some things have changed!'.

My initial reaction to this is that this is a bad idea for existing users, whether they have custom keybindings or entirely use the defaults, because everything is going to be different for them. I'd recommend a popup on each startup with a "don't show again" with a notice about this, and a button that says "try these new keybindings" and a setting (with instructions) after you try it, to show you how to opt back into the old keybindings. This way you don't break any expectations/keybindings for anyone.

[thesoftwarephilosopher]

I've decided that if we aren't sure whether to add a confirmation panel for something, we should add it. Long-term users will develop the muscle memory to hit 'enter' after the original keybinding so it won't slow them down. We can also allow configuration which removes confirmation panels for things a user might regularly do.

👍 solid plan

[MikaelElkiaer]

Here are some random thoughts based on the previous comments.

I'd actually prefer a lot fewer key bindings. I prefer keybindings for stuff I do often and that requires context - such as highlighting or selecting items in lists. If I only have a few of the mostly used keybindings, I'd hit ? or x and quickly search for the uncommon action I'm about to do. This would require a lot less alphas to be in use, and avoid many of the actions with illogical keymaps.

I am a heavy vim user and could also see use for combos or leader key. I would very much like to avoid modifiers as much as possible. I love how hjkl works in lazygit. Enter/esc as well.

I'd prefer better integration of my default text editor than multiline, or otherwise extended, text fields.

How about using more icons to indicate state - in the areas where colors fall short. (Based on the commits discussion).

[jesseduffield]

Thanks for the feedback all! I'll slice off an easily actionable part of this: confirmation panels. I just did an audit and here's what I think:

things that need confirmation: anything that switches to subprocess anything that changes the commit log (except checking out branches) destructive actions

things that don't need confirmation: opening things in a separate program (e.g. opening a PR in browser) copying to clipboard opening a menu things that you do very frequently like staging files, checking out branches

things that should have confirmation and currently don't:

• reword commit with editor
• move commit up/down outside rebase mode
• edit commit
• revert commit
• undo/redo
• add to gitignore
• initialising a submodule
• applying/popping stash (addressed in https://github.com/jesseduffield/lazygit/pull/1714)

Things I'm not sure about:

• edit file
• commit message in editor I assume both of these are used frequently by some users. At the least we should have a configurable confirmation here, but not sure what the default should be.

[mjarkk]

More confirmation panels

Compared to @peppy i do actually very often press keys accidentally and break things. This is mainly because Lazygit was focused while i expected something else to be focused and just start typing. As keybindings in Lazygit are just letters typing out a word can do some damage. I can see why some people like not to have any prompts as they are annoying tough for me a very clumsy person i would like to at least have an option to show prompts before doing stuff.

[MikaelElkiaer]

I think I'd prefer a leader key for any action that would prompt a confirmation box - as an alternative fix for accidental presses.

Edit: Something along these lines would be pretty cool and useful: https://github.com/liuchengxu/vim-which-key So that you have a group of actions with a specific activation key, which will bring up a view which will show a keymap for the actions in that group.

[peppy]

@mjarkk interestingly i touched on a similar thing in my original text, where i accidentally paste into lazygit (or paste more than i was expecting to). that said, confirmation dialogs have a limited save in that case, because if you hit the confirmation key and keep typing you're still going to get in a weird state. i guess it reduces the chance of this happening via manual input though :)

[jesseduffield]

@mjarkk I'm not sure how much we could do to help with typing a series of commands, but I certainly forget which keys map to what (e.g. 'r' could mean rebase/reword/revert) and accidentally do the wrong thing. A confirmation panel would spare me from doing that at least.

@MikaelElkiaer I don't have any experience using a leader key myself and I have a slight bias against them just because it sounds like it adds friction, but I'll try to get a feel for it and see if it's a good fit for lazygit. I do like the idea of easily seeing all those keys on-screen though.

@peppy something that just occurred to me is that if we defaulted to multi-line prompts treating newlines (i.e. the enter key) as actual newlines in the text, that would potentially fix your issue, given that the only other valid key in that situation is escape (or ctrl+enter let's say to submit). Also, did you have a preference against adding a confirmation for editing a file or opening the commit editor in a subprocess? Do you think that would add unnecessary friction to your workflow?

[peppy]

I'd have to try and see how it feels, to be honest. Probably a non-issue.

And yes, multi-line inputs would largely solve the issue I have encountered.

[Ryooooooga]

First of all, before I started using lazygit, I also tried tig and gitui.

I finally decided to use lazygit instead of those because the key bindings for basic operations (enter, esc, space, and arrow keys) felt more natural.

Left/Right keys

I only use the left/right keys to move panels.

Global keybindings

No global keybindings should have context-specific overrides. E.g. if 'R' means refresh globally, no panel is allowed to define its own 'R' keybinding (at the moment it will have you reword a commit in the editor without any confirmation panel). Some exceptions can apply if we still provide the option to do the global thing in a menu e.g. pressing 'P' when you've selected a tag should ask you if you want to do a regular 'push' or just push that tag.

looks good. Overriding can be confusing for beginners (and me).

Removing items

Any place we use 'd' to remove an item, we should also be able to use 'backspace' and 'delete'.

Looks good, but they might expect rm instead of reset for backspace.

Selecting a range of items

It is very rare that I use v for multi-line staging.　 I always end up hitting space repeatedly. (I understand that v means vim's visual mode but space is quite easy)

Menu-specific keybindings

I often need to hard-reset onto a commit and I don't like having to press 'g' then down twice, then enter. That's four keypresses for something pretty trivial. Reordering those menu items is out of the question given the damage it can do, but what would be great is to be able to specify keybindings for each menu item e.g. 's' for soft reset, 'm' for mixed reset, and 'h' for hard reset. That way I just press 'gh' and I'm done.

This sounds good for both beginners and experts.

More confirmation panels

Pressing enter doesn't take that long, especially if it's in your muscle memory. We should have a confirmation panel for anything that can get you into a state that's hard to reverse or escape from. This includes the keybinding for rewording a commit in your editor.

I often use amend commit and have never been frustrated by prompt.

Should we include confirmation panels if you've selected an item in a menu? I'm not so sure. That's going to be less accident-prone compared to pressing a random key outside a menu.

I think it would be better not to include.

Multiline prompts

The only multi-line prompt right now is the commit message panel. We need to decide on one of the following:

1. enter key always submits, alt-enter (or ctrl-enter) adds newline in multiline prompt
2. enter submits in single-line prompt, alt-enter (or ctrl-enter) submits in multiline prompt (and enter adds a newline)
3. something else

1. is the best for me.

I use lazygit only for single line commit messages, otherwise I use editor or commitizen.

things that need confirmation: anything that switches to subprocess anything that changes the commit log (except checking out branches) destructive actions

things that don't need confirmation: opening things in a separate program (e.g. opening a PR in browser) copying to clipboard opening a menu things that you do very frequently like staging files, checking out branches

:+1:

things that should have confirmation and currently don't:

reword commit with editor move commit up/down outside rebase mode edit commit revert commit undo/redo add to gitignore initialising a submodule applying/popping stash

Basically :+1:. As for git stash apply, personally, I don't need it.

[jbrains]

Just commenting to say that I haven't felt any strong disagreement with any of the foregoing, so my feedback so far is a mildly reassuring "keep going; nothing stands out here for me to yell against". Where git is concerned, I favor safety over speed, so I support any decision that adds safety. Having keyboard navigation through menus provides all the speed I need from lazygit and I've really become very happily accustomed to that in the past year.

[fluffynuts]

Came here to say something similar: I've read what's here and don't feel like I have something to add, but I'm grateful for being included in the conversation.

[thesoftwarephilosopher]

There's way too much here for me to comment on already, and it's not in a structure/format that's very easy to comment on, and my feedback is not worth any more than anyone else's here, so I'm probably not going to be much help at this point. Thanks @jesseduffield for taking my feedback into consideration, and thanks to you and everyone else for making this useful app.

I'm using your app the most so far lately, so I guess that means I like it best. Your staging file panel is great, I like that I can see all files in the same place whether staged or not. I'd like it if unstaged/staged panels would always both be visible, if that can be made an option. Then I can easily stare at one side while navigating the files panel.

[jesseduffield]

@David-Else could you please make a separate issue for this? This thread is more about general UX concerns

[prosoitos]

No global keybindings should have context-specific overrides.

YES!

I am currently unable to map scrollUpMain to p as I would like to do because when I am on the Commits panel, this pulls (even though in the global kbd, I have attributed a different key to pull and all works well from other panels). No amount of fidgeting allowed me to by-pass this weird context specific behaviour.

So I think that this would indeed be a great improvement 🙂

[prosoitos]

I have wanted to open an issue about a feature request for a very long time and maybe here is the place to mention this. Apologies if this has been discussed already:

I would love to see classic Emacs kbd which work by default on most terminals and so many other places implemented in the commit message popup.

Things like:

C-b: move backward one letter
C-f: move forward one letter
C-k: kill to the end of line

Until recently, whenever I would use one of these (out of habit), everything would get garbled in a very strange way with future letters appearing in unexpected place and not below the cursor. The only way to get out of this mess would be to cancel the commit and start over. This crazy behaviour has stopped, which is great 🙂 But having those kbd actually work would be really sweet.

[prosoitos]

Another thing that I have meant to mention for a long time:

After pressing x (so when the menu is open), it would be convenient to be able to directly press the key to have an action done (instead of first having to close the menu and then press that key or scroll down to the key, which can be a bit tedious).

For instance, if I don't remember that the kbd to open a file is o, I would press x, see what key is the one I am looking for and I could then directly press o to open my file.

[prosoitos]

Since I am at it, I would like to say once again how impressed I am with lazygit. It is a really amazing tool, I use it all the time, and it has transformed my daily workflow with Git. And, amazingly, it keeps getting better and better with added functionalities and little quirks and odd behaviours disappearing.

Thank you very deeply for your great work @jesseduffield ❤️

Note: I give workshops and webinars to academic researchers on computing tools and I have promoted it by giving webinars on it because I think that it really is a tool that can benefit them 🙂

[jesseduffield]

@prosoitos I'm blushing!

Your point about adding more keybindings to the commit message editor (or any prompt panel) makes sense, and should actually be easy to implement.

The idea of having menu items with their own keybindings also makes sense and is something I want to implement soon.

[prosoitos]

Still on the subject of adding kbd to the commit message editor:

The ability to copy-paste in commit messages (if not too challenging to implement) would also be very useful (e.g. when making several similar commits in a row).

[jesseduffield]

I've made some slight progress on this issue. I've got some confirmation popups for some keybindings, and I've just merged https://github.com/jesseduffield/lazygit/pull/1841 which adds per-item keybindings to menus.

[peppy]

Confirmation on editing a commit is a bit of a weird one to me (editing something doesn't feel to me like an action that needs a pre-confirmation step so it surprises me when I see it). Will see if I get used to it over time.

[jesseduffield]

@peppy happy to add an override option in the config for it

[MikaelElkiaer]

Confirmation on editing a commit is a bit of a weird one to me (editing something doesn't feel to me like an action that needs a pre-confirmation step so it surprises me when I see it). Will see if I get used to it over time.

I guess this depends on the current state - if it is not the latest commit or it already has been pushed, then the consequences are much larger.

[peppy]

That's a fair point. If you begin editing a commit message and decide you don't want to after all the only way to cancel would be to remove the full message and cause git to error, which may be non-obvious to some.

[daveriedstra]

I would love to see classic Emacs kbd which work by default on most terminals and so many other places implemented in the commit message popup.

I'm not an emacs user, but some of these keybinds have just become second nature due to spending a lot of time in the terminal. Ctrl+w to delete the previous word is a big one for me. In python there's at least one package for getting these keybindings (urwid_readline), maybe there's something similar in Go?

I'll also add that Ctrl+Left and Ctrl+Right to navigate by words would be great as well.

(I'll also add some more love for lazygit, it's great and has become my primary interface to git. Thank you!)

[prosoitos]

I'll also add that Ctrl+Left and Ctrl+Right to navigate by words would be great as well.

In most terminals, you can also use the Emacs kbd M-f and M-b to navigate by words.

(By M-f, I mean Alt+f and by M-b, I mean Alt+b).

[MikaelElkiaer]

So many advocating for Emacs-esque bindings. I want to put in a word for vim-esque bindings. Ideally, it would probably be a mix of the two and an option to choose which one to be predominant.

[daveriedstra]

vim-esque bindings

What do you have in mind for this? IMO, the commit message editor is too small & brief of an interaction to benefit from a vim-like modal editing, which is where vim keybinds really shine. I'm pretty sure all the bindings I use in insert mode are emacs / readline or plugin-based. (Not to mention that a modal editor would be a ton of work to build out & support compared to what is hopefully just finding the right library for readline keybindings and plugging it in (not to downplay that work...).)

[mark2185]

I agree with @daveriedstra, vim keybindings seem like overkill. For the cases where I need vim bindings I'd just press C to open up the commit in the external editor.

But the <c-w> seems the most useful and would like to have that.

[jbrains]

I would like to add a very strong vote for "don't try to reimplement a text editor". Instead, I recommend encouraging users to use their own text editor for composing and editing non-trivial commit messages. Indeed, I would strongly recommend a tutorial video and/or article about this, emphasizing it as an intentional constraint.

I remember asking for UI enhancements for editing commit messages, because my brain was stuck in the mode of "I must compose my commit messages here". When someone reminded me that I already have a world-class text editor on my machine (in my case, kakoune), everything became simpler for me. Now I almost always compose my commit messages in my editor and use lazygit's UI for that only when the message is very short. And when I make a typo, I end up using my editor to reword the commit comment, anyway.

This way we don't have to entertain the argument about Emacs bindings v. vim bindings, especially since lazygit is already clearly vim-leaning and therefore there is really only one logical choice. ;)

[daveriedstra]

the argument about Emacs bindings

I broadly agree with you, though I do think there's a good case for Emacs bindings in the short commit editor. They're fairly ubiquitous in the shell & TUIs (even in vim!), so users might be expecting them, and even though the builtin message editor is (and maybe should be) constrained, correcting a word early in the message currently requires holding down a key for several seconds (either Left to navigate there or backspace to rewrite the whole message), which is pretty interruptive for what's supposed to be a shorter action. I don't agree that fixing a typo should require breaking out into a separate program for the same reason, though as you mentioned that workflow is complementary.

[jbrains]

I don't agree that fixing a typo should require breaking out into a separate program for the same reason.

Fixing a typo doesn't require this, but using your fully-powered editor, the one you use every day and know inside and out... that seems like a good idea to me, especially compared to holding down a cursor key and missing your spot or training your fingers to use a new set of key bindings for just this one task.

But the good news is that we don't need to disagree here. As long as it remains fast and easy to edit a commit message using the system editor, I'm happy. If others prefer to use Emacs keybindings in the lazygit commit message editor (for the perfectly reasonable reasons already stated here), I don't necessarily want to stop them, although I would want them to be reminded that they can use their system editor. (And I wouldn't be in any hurry to give them a not-quite-text-editor to do it.) Let them choose!

[daveriedstra]

Totally with you on that!

On the topic of the external commit message editor: I wasn't even aware it was an option in lazygit until the comment earlier in this thread. Maybe there's a way to emphasize it somehow.

[MikaelElkiaer]

Not gonna ping anyone, as I got multiple and various responds. Regarding what I said about vim-esque bindings - I meant in regards to navigation and actions - not text editing. As some, if not all, also mentioned, it makes more sense to use a more full-blown editor of choice for non-trivial text editing.

More concretely what I was hoping for, was the use of combos (perhaps leader key) for actions, rather than using modifiers.

[mark2185]

in regards to navigation and actions - not text editing

Could you expand upon this, what exactly did you have in mind? I'm having a hard time imagining it.

[MikaelElkiaer]

in regards to navigation and actions - not text editing

Could you expand upon this, what exactly did you have in mind? I'm having a hard time imagining it.

https://github.com/folke/which-key.nvim Some screenshots and texts here somewhat explanatory. Note that this plugin is just visualization of key mappings.

But basically, some keys will require one or more additional keypresses in order to actually do something. E.g. b m to merge a branch, b r to rebase. c r to rename a commit, c a to amend a commit. But can also be 3 keys, or just 1.

[mark2185]

E.g. b m to merge a branch, b r to rebase. c r to rename a commit, c a to amend a commit. But can also be 3 keys, or just 1.

Ah, I thought this was still about writing the commit message.

Well we have some sort of mappings for menus, and then subsequent entries which is better than nothing, but I do get your point. "Global" mappings sound great, but again, backwards compatibility is a bitch.

[jbrains]

I meant in regards to navigation and actions - not text editing

I am very very very strongly in favor of sequences of multiple keys if that results in a nice command language of "object, verb". This matches very well with kakoune, so it's perfectly for my mind. For example, I love the idea of "c, r" for "commit, reword".

A common architecture for such commands would be very welcome. I vote for "object, command". Even so, I can get used to anything, as long as it's consistent. My fingers can learn anything. :)

[prosoitos]

So many advocating for Emacs-esque bindings. I want to put in a word for vim-esque bindings.

Only because those work by default in the vast majority of terminals out there.

I am not trying to advocate for Emacs-esque kbd, but for terminal-esque kbd.

I would like to add a very strong vote for "don't try to reimplement a text editor".

Exactly! My suggestion about those shortcuts are not to turn lazygit into an Emacs keybinding based utility, but so that the little quick popups behave more like one would expect from a terminal.

I personally agree that we don't need to go into terribly complex text-editor capabilities.

[prosoitos]

I do think there's a good case for Emacs bindings in the short commit editor. They're fairly ubiquitous in the shell & TUIs (even in vim!), so users might be expecting them.

Right: this is very precisely where I was coming from with my suggestion to implement those in the quick commit editor 🙂

[jbrains]

I do think there's a good case for Emacs bindings in the short commit editor. They're fairly ubiquitous in the shell & TUIs (even in vim!), so users might be expecting them.

Right: this is very precisely where I was coming from with my suggestion to implement those in the quick commit editor :slightly_smiling_face:

For those of us who use vi editing more in all our shells, this would just be one more reminder that emacs is the default and that the rest of the world just doesn't know any better. :stuck_out_tongue_winking_eye:

[Bhanukamax]

I would love to see classic Emacs kbd which work by default on most terminals and so many other places implemented in the commit message popup.

I'm not an emacs user, but some of these keybinds have just become second nature due to spending a lot of time in the terminal. Ctrl+w to delete the previous word is a big one for me. In python there's at least one package for getting these keybindings (urwid_readline), maybe there's something similar in Go?

I'll also add that Ctrl+Left and Ctrl+Right to navigate by words would be great as well.

(I'll also add some more love for lazygit, it's great and has become my primary interface to git. Thank you!)

`Ctrl+w is a big one for me too, I use it often in vim insert mode too, as far as I know ctrl+w comes from the gnu readline shortcuts. I think it would be very useful if the actual readline library can be used for text input so all of those things will be available for text input.

https://pkg.go.dev/github.com/chzyer/readline#section-readme https://github.com/chzyer/readline/blob/v1.5.1/doc/shortcut.md

But I am not sure how feasible it is, I tried to read through the lazygit codebase to see if I can try that, but I'm not that familiar with go and TUI applications development in general.

[Ryooooooga]

@Bhanukamax C-w is already implemented.

[Bhanukamax]

@Bhanukamax C-w is already implemented.

that's nice, I wasn't running from git, now I switched to using from git/master and it looks like a lot of useful readline shortcuts have been already implemented. I just missed 3 main other things I use on terminals, etc, Alt-b(go back a word), Alt-f (goto the beginning of next word), Alt-d (delete next word), I saw some of it was already implemented with Alt+Arrow keys.

I implement a hacky version of Alt-b, Alt-f and Alt-d for my own usage, I have no idea how to properly do it for a pull request. I had to change some of the code in vendor/gocui which is a separate git repository altogether, so this is clearly not the correct way to go about it, but I'll leave a link to my implementation in case it's useful.

https://github.com/Bhanukamax/lazygit/pull/1/files

[soluty]

is there any way to bind a key sequence ?? i have not find something in doc, i think support this will make the keybind ux better. maybe i can use "gg" to goto the first item of a list?

that means people can make keybind with namespace . and will make the keybinding more meanful, and dont need menu specific keybinding anymore.

[mark2185]

is there any way to bind a key sequence ??

Currently there isn't. While I do agree it would free up the keyboard real estate, I'm not sure what the plans are regarding it.