Multiline commit messages

[MartinPetkov]

There should be a way to write multi-line commit messages. For example, you could use Enter for newlines and Shift+Enter to commit.

[flipsi]

I would suggest opening the user's editor for the commit message. This is how it's done in https://github.com/jonas/tig and also has the benefit of giving the user his own (probably customized) text editing environment.

[jesseduffield]

I agree @Sflip, I've got a PR up now that's made a start on opening e.g. vim as a subprocess, but I can't quite get it working. Any help on that and would be much appreciated :)

[cmoesel]

If you're keeping track, I'd be totally fine with (and probably prefer) @MartinPetkov's suggestion to have a simple mechanism for multi-line commit messages without having to leave lazygit (i.e., no launching another editor). But... I'll gladly use whatever you choose to provide. ;-)

[jesseduffield]

@cmoesel at this point the in-lazygit solution is certainly the more straightforward one. I'll see if we can get this subprocess thing off the ground in the next couple of days and if not I'll (or somebody else is invited to) put a PR up for the simple solution

[ponsfrilus]

💡 It would be awesome to consider the commit.template git variable !

[from-nibly]

It would also be cool if you could open and close the commit message dialog without losing your message. I often build a large commit message while trolling through the changes I made step by step.

[jesseduffield]

I've come up with two solutions (with the help of @from-nibly ), both of which are in the latest release:

1. because gocui doesn't support shift+enter, and the enter key is reserved for submitting the commit message, I've gone with using the 'tab' key to enter a newline at the commit prompt. If anybody thinks a better key is applicable let me know and I'll change it :)

2. If you hit shift+C you'll open up a commit message in your editor (usually vi) and upon saving the commit message will be used.

As for point 1, you can now escape the popup commit message panel and reopen it without losing what you wrote

@ponsfrilus if you use the shift+C approach your commit.template will be used

Let me know if you guys have any concerns/questions :)

[ponsfrilus]

Cool for the shift+C. I have to say that I was used to TAB to switch pane (as for the down arrow).

[jesseduffield]

Yeah it's not an ideal situation, but I can't really think of any other key that you're unlikely to need in actually typing the commit message. gocui uses termbox under the hood so the best you get from it is using the alt key (or maybe it's the command key I'm not really sure) but that's already linked to all kinds of stuff with people's individual hotkeys

[ponsfrilus]

Yeah I saw that when I lookup why shift+tab wasn't doing the opposite of the tab key. Termbox just doesn't implement that and it doesn't feel that simple to add it...

[jesseduffield]

Yeah it would really make a difference having shift as as 'modifier'. People could use shift+down instead of right to go to the next panel for example. Ah well

[MartinPetkov]

I agree, Shift+Enter would be great, but I'm personally fine with Tab for now. I just tried it out and I'm happy with it, so I'm closing the issue.

Thank you for the quick response and the good work! I've been using lg over the past week and I've enjoyed it.

[from-nibly]

I know this is closed but what if you went with vim keys instead. q to close the commit while clearing the message, esc to save the message but close the window, w to commit, and enter for newlines?

@jesseduffield

[jesseduffield]

@from-nibly this wouldn't just be a matter of rebinding keys: it requires a sense of 'mode' to be stored so that when you're in insert mode and press 'q' it actually prints a 'q' rather than close the panel. I'd happily merge a PR that implements this :)

[jbrains]

I know that this issue is closed, but I stumbled upon an inconsistency in the UI, so I wanted to mention it here first before opening a new issue.

The multiline comment behavior differs between the Commits > "reword commit" action and the Files > "commit" action. In the first one, wrapping happens automatically, but in the second one, I need to use the TAB key to enter a newline and there is no automatic wrapping. I can't judge whether you intended this, but the inconsistency seems odd to me. I like the idea of opening the editor to draft longer commit comments (from both actions); whatever you decide, I imagine the UI ought to behave the same way in both cases.

If you intended this difference in behavior, then I don't mind it enough to propose changing it. :)

[MinmoTech]

Furthermore, while rewording already existing multi-line commits, I cannot navigate to lines below the first one, I can only enter new newlines with tab.
Is there the possibility of renaming commits in an external editor?

[jesseduffield]

@juligreen you can rename commits in an external editor via shift+R

@jbrains I agree the two interfaces should be the same. Would you prefer wrapping in both cases?

[MinmoTech]

Thank you, and sorry for not reading the keybindings properly!

[jbrains]

@jesseduffield Hm! I'm not sure. I think I prefer manual wrapping (so as to avoid eventual configuration settings and resulting bikeshedding), but then TAB is a fairly unexpected character to use to insert a newline. I would expect to use Shift+ENTER, for example, to insert a newline in the middle of a commit comment when ENTER behaves as "submit".

[dsnoeck]

What about the opposite? In a textarea ENTER add a new line. Le mar. 13 oct. 2020 à 16:09, J. B. Rainsberger <notifications@github.com> a écrit :

@jesseduffield <https://github.com/jesseduffield> Hm! I'm not sure. I think I prefer manual wrapping (so as to avoid eventual configuration settings and resulting bikeshedding), but then TAB is a fairly unexpected character to use to insert a newline. I would expect to use Shift+ENTER, for example, to insert a newline in the middle of a commit comment when ENTER behaves as "submit". — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#28 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFH6RQUHLJIULIZV4OX2CTSKRNR7ANCNFSM4FN67Q5A> .

-- Damien Snoeck

[jesseduffield]

If shift+enter were a permissible key I would certainly use that, but we're in an unfortunate situation where we can't really use enter with any modifier key (shift/cmd/ctrl). Luckily the keybindings are configurable in the latest release so you can remap the 'appendNewLine' and 'confirm' keybindings in the commit message panel to whatever you want.

As for defaults, I think most people only write commits with a single line so enter would be better for them. If we made enter append a newline by default, users would get confused about how to submit the commit message. I completely agree that using 'tab' to enter a newline is awkward though. Maybe there could be some other key to toggle you in and out of multiline mode where enter either appends a newline or submits the message depending on the mode you're in.

[jesseduffield]

(just realised that branch actually isn't merged yet but SOON those keys will be configurable)

[jbrains]

@jesseduffield Thank you for describing the constraints; I didn't know about them. Given those constraints, I don't think I'd have decided significantly differently. I strongly agree with optimizing the user experience for a single-line commit message.

I don't remember what it felt like to learn that TAB was the right key for entering a newline character, so I can no longer helpfully recommend how to make that aspect of the user experience nicer. Once I know how to do it, I don't mind typing TAB, since I can't imagine using that key for any other purpose in a commit message. The mode idea would be interesting, if for no other reason, than because it's thematic, reminding one of vim. In your shoes, I wouldn't volunteer to spend much energy on it. The consistency of behavior matters to me in a way that the newline key truly doesn't.

Thank you.

[jesseduffield]

@jbrains good to hear :) Could you raise an issue about the inconsistency?

[DraganGrbic-TomTom]

Maybe enter for new line, enter-enter to commit? So we could have both ways, just remove last newline on enter-enter and here we go, on single line commit messages we just need to press enter twice. On multiline messages, after last line press enter twice.

[sl4mmy]

What about using the up & down arrow keys to dynamically resize the commit message window? I understand the reasoning behind using to insert a newline, but it still feels a little weird to me.

My initial spike using up/down to resize the window is here: #1204

[jesseduffield]

@sl4mmy thanks for making that PR, I gave it a test and it seems straight-forward enough. I'm interested to gauge other people's thoughts on that approach too.

I did some digging myself and found that using the tcell library we can handle an alt+enter key combination. I've got a branch up that I'm yet to complete which switches our terminal dependency to tcell and I've made a spike PR off that for a POC. Let me know your thoughts: #1207

[jbrains]

@sl4mmy thanks for making that PR, I gave it a test and it seems straight-forward enough. I'm interested to gauge other people's thoughts on that approach too.

This sounds promising. I'm certainly happy to try it.

[theduke]

Is supposed to work at the moment for adding a newline to the commit?

This is currently not working for me. (lazygit 0.29)

[anvandaren]

Just tried using TAB to create a new line in a commit message in lazygit 0.30.1 in GNOME-terminal 3.28.2 and it did not work. Shift+C to open the git editor worked. @jesseduffield has this feature been removed?

[jesseduffield]

@anvandaren I don't actually recall removing the 'tab' key but it looks to indeed be removed. You should be able to use cmd+enter on mac or alt-enter on windows to get the same behaviour now

[anvandaren]

@jesseduffield Ok thanks, Alt+Enter is better than TAB!

[WolffTech]

I am unable to use Cmd + Enter or Option + Enter on macOS to create a new line on a commit message. Personally I preferred Tab for new line.

[jesseduffield]

@WolffTech you should be able to get back the old behaviour in the config with:

keybinding:
  universal:
    appendNewline: '<tab>'

[Manuzor]

On windows, alt+enter is the conventional default to toggle fullscreen and it's the case for conhost, windows terminal, and alacritty in my testing.

In windows terminal I removed the keybinding in Settings▶Actions▶Toggle fullscreen. I had two bindings near the bottom of the screen, one with F11, one with alt+enter.

As for alacritty, you can rebind alt+enter with the following config:

key_bindings:
  # From the docs: "To unset a default binding, it can be mapped to the `ReceiveChar` action."
  - { key: Return, mods: Alt, action: ReceiveChar }

No idea about conhost.

Hope this helps someone.

[mark2185]

@Manuzor this won't be needed once #2390
gets merged :)

[jesseduffield]

speaking of which, I'm looking at that PR right now, hoping to address a couple remaining issues

[Manuzor]

Ah, thanks for the hint. I'm new to lazygit and don't follow lazygit development (yet) so I had no clue there was movement in this area. :) Thanks for making it happen!