About the new commit message panel

[Saafo]

Topic
We have the new commit message panel here: #2390, but I met some issues:

1. How to enter my own $EDITOR to edit commit messages? Because I'm more familiar with my own editor.
2. [BUG] The bottom line still shows something like "1-5 jump to panel..." when editing the commit description, which is a bug IMO

[mark2185]

Pressing C allows you to open up the editor to commit what you want, and pressing R in the Commits panel allows you to reword the selected commit in your editor.

In case the editor is not what you expected, check both $EDITOR and core.editor in your gitconfig.

[Saafo]

Pressing C allows you to open up the editor to commit what you want, and pressing R in the Commits panel allows you to reword the selected commit in your editor.

Got it, C and R is available in the main menu.

However, I guess I'd like something like, editing with the builtin commit message panel, but I change my mind and decide to continue editing in my own editor, which is available in gitui.

There might be two approaching to this feature:

1. provide something like "ctrl+e" in the commit message panel, to jump to $EDITOR with the editing message.
2. press C or R to open $EDITOR with the editing message already in the commit message panel(since we can remember the editing message in the panel even if we quit the panel)

[mark2185]

While it does sound useful, it does also sound like it would needlessly complicate things because we'd have to store the current content somewhere and use that as a template for the new commit. It'd be easier to get used to editing in $EDITOR all the time.

I change my mind and decide to continue editing in my own editor

A workaround would be to commit what you have written so far, and then reword the commit in your favorite $EDITOR.

[Saafo]

because we'd have to store the current content somewhere

I think this is already be implemented, because if I type "test" in commit panel, exist the panel, and reopen the panel, the "test" still exist (but I'm not sure whether the "test" is stored in some data model or just in the panel UI component and the component isn't destructed after disappearing, so the "test" remains here.)

A workaround would be to commit what you have written so far, and then reword the commit in your favorite $EDITOR.

I think it's a nice workaround currently.

[mark2185]

I think this is already be implemented, because if I type "test" in commit panel

It is, but for providing that the underlying git command one has to save it into a file somewhere and execute git commit --template /path/to/the/saved/content and then cleanup the file (or is that done automatically?)

In any case, if several users have a need for that it'll be looked into, but for now, I hope the workaround is simple enough.

I'd still advise using commit.verbose = true git config option and using your $EDITOR.

[jesseduffield]

I think this is worthwhile because our internal editor is currently lacking compared to something like vim. The only question is which key binding to use

[Saafo]

I think this is worthwhile because our internal editor is currently lacking compared to something like vim. The only question is which key binding to use

gitui is using ctrl + e, I'm not sure whether it's suitable.

[jesseduffield]

Works for me!

[stefanhaller]

I would like to have this feature too, and I'm interested in trying to implement it. I see a few problems though:

• If we implement it in terms of git commit --template as @mark2185 suggests above, we can only do it for "commit" but not for "reword". --template is ignored if you pass --amend, it will always use the original message in that case.
• Also, when using --template, if you hit <c-e> but then decide that the message was actually fine already and you just close the editor window, the commit will fail with "Aborting commit; you did not edit the message." Probably not desirable.
• Which means that we should probably spawn the editor ourselves and then pass the message to git using git commit -F. The disadvantage of that approach is that we don't get git's usual additional stuff in the editor window, e.g. which files are changed, and the diff if commit.verbose is on. We'd have to generate these ourselves; might not be too hard actually, but still feels awkward.

Any opinions on which approach to take?

[mark2185]

The disadvantage of that approach is that we don't get git's usual additional stuff in the editor window, e.g. which files are changed, and the diff if commit.verbose is on.

I tried running git commit --edit --file=asdfile with garbage in asdfile and I do get the verbose content, so that may be a viable approach. And it can even read from stdin so we don't have to trash the filesystem with temporary files.

gitui is using ctrl + e, I'm not sure whether it's suitable.

Works for me!

Something something about wanting the editor to support emacs mappings such as ctrl+a, ctrl+e, ctrl+w and others comes to mind, I know there was a discussion regarding that, but I don't remember what came of it. The choice of ctrl+e might make people grumpy.

[jesseduffield]

Ah yes, good point. How about a keybinding that opens a menu which lets you pick an option to open in editor? We could then add more things to that menu like setting the --no-verify flag (our current implementation for WIP commits is hacky)

[mark2185]

The menu should have a checklist then so that we can go back-and-forth between the menu and the commit, or in case we want several options, e.g. allow empty commit, no verify. But it does seem like a step in the right direction.

[stefanhaller]

I tried running git commit --edit --file=asdfile with garbage in asdfile and I do get the verbose content,

Ah, nice. Yes, that works, even with --amend.

How about a keybinding that opens a menu which lets you pick an option to open in editor?

Sounds good, but we still need to find a good key binding for the menu. Suggestions? Maybe <c-o> for "Options"?

[stefanhaller]

This (well, something like this 😄) was implemented in #2881. Closing.