[mini.git] tabmove in MiniGitCommandSplit with :Git commit/rebase

[drowning-cat]

About

MiniGitCommandSplit is not triggered for :Git commit or :Git rebase.

I understand that MiniGitCommandSplit fires when the command has completed, so it makes sense that it doesn’t trigger while the command is still in progress. However, for these commands, the name of the event might be a bit misleading.

Perhaps for commands like these, it should fire once they are displayed in the tab, or it might make sense to introduce a separate event, such as MiniGitCommandSplitInit. That said, the only use case I see for such behavior at the moment is adjusting the tab positions for these commands.

[echasnovski]

It is an expected and documented behavior, yes. As those do not show Git's stdout, but act as a GIT_EDITOR.

Could you please elaborate on the actual problem this is causing?

[drowning-cat]

I initially discovered this when trying to move the commit/rebase tab using tabmove(-1):

Currently:

| init.lua | COMMIT_EDITMSG | other tab |
             ^ close (current)
| init.lua | other tab |
             ^

After running tabmove(-1):

| COMMIT_EDITMSG | init.lua | other tab |
  ^ close
| init.lua | other tab |
  ^

Note

So the problem is that after closing :Git commit tab, neovim cycles to the next tab.

See #2097 (reply in thread).

Later, I found that this issue can be handled more easily using the TabClosed event together with the :tabprev command, although it still has a few edge cases:

• When a new split is created in the commit/rebase tab, closing that window sends the wrong buffer to the event.
• If :set buftype=wipe is used, the buffer is no longer available in the TabClosed event.

[echasnovski]

I am not 100% sure I understand the problem of how this is tied with :Git commit, but glad that it seems to be solved :)

Can a different 'tabclose' option help here?

[drowning-cat]

Yes, definitely. I just didn't know (or forgot) about tabclose option 😮😅.
Sorry for bothering you, thank you ❤️.