Key presses produce incorrect input since v0.58.0

[ahmetsait]

Describe the bug

Some key combinations produce incorrect input and triggers unrelated actions as a result.

To Reproduce

• Trying to move a commit with Ctrl+J acts as if Enter is pressed and shows the files of the commit instead.
• Trying to submit a commit description with Alt+Enter writes the letter "m" into the text area.

Expected behavior

To do what it did in v0.57.0.

Version info:

commit=2f6d20275afd5fc9b623500c9194a2c732936014, build date=2026-03-09T19:51:31Z, build source=binaryRelease, version=0.60.0, os=windows, arch=amd64, git version=2.53.0.windows.2

Terminal info:

Ctrl+J issue only happens in MinTTY (Windows). $TERM = xterm-256color
Alt+Enter issue happens in both MinTTY and Kubuntu Konsole but not in Alacritty. Alt+Enter is a shortcut for toggling full-screen on Windows so you need to disable it on MinTTY options for lazygit to receive it.

Additional context

This regression is most likely caused by the recent TUI library migration on v0.58.0.

[stefanhaller]

I feel this might become obsolete with the larger keyhandling revamp that I'm planning to do, so it might not be time well spent to look into this before that.

But also, I'm wondering about the importance -- why not use Windows Terminal?

[ahmetsait]

On Linux I don't think there is a port of Windows Terminal, nor would I care about using it even if it did exist. I use Konsole or Gnome Terminal or whatever the default is for my environment.

On Windows I stopped using MinTTY (because it is dog slow) but this issue isn't just about MinTTY. And even then MinTTY is what Git for Windows recommended for a long time (still does?) so yes it's not as big of a deal for me but a lot of people continue to use it.

This bug might also be an indication about a more fundamental issue related to input or terminal compatibility in the codebase so it's worth looking into the root cause.

[stefanhaller]

Ok, so that's two different issues then.

I spent quite a bit of time today on investigating the Ctrl-J issue. This was introduced with gdamore/tcell@eae68825608b (mind the commit message), and I can only suspect that MinTTY has a bug in win32-input-mode (it sends a CR character with the ctrl flag set, which is clearly wrong). I can see how, from the perspective of a lazygit user, this looks like a lazygit regression (worked before 0.58, no longer works after), but there's really not much we can do here if we switch to a newer, more modern protocol and the terminal emulator has bugs in that new protocol that it didn't in the legacy one. Mind you, I'm not an expert at this terminal protocol stuff, so I might be diagnosing this wrong; feel free to research this more deeply if you want to, but I exhausted my time budget for this.

As for the Alt-Enter issue: unfortunately this is a key combination that is notoriously poorly supported by terminal emulators, that's why we added the alternative Ctrl-S binding in #4532. In the future we will be able to switch to Ctrl-Enter on Windows (Command-Enter on Mac) once the mentioned revamp of the keybindings code is done.

[ahmetsait]

I really appreciate your investigation.

I don't think MinTTY supports win32-input-mode at all and my searches don't bring up anything that says otherwise.
Something I was a bit suspicious of was terminal line settings about newline (onlcr and inlcr) but that doesn't seem to make sense for Windows.. unless some funky Cygwin business is going on.

I'll be testing once the keyboard revamp is live.

Thanks a lot.

[stefanhaller]

I don't think MinTTY supports win32-input-mode at all

Hm, looks like it. Judging from this comment it seems that MSYS2 is somehow involved in providing this. Frankly I don't understand these things enough to tell what this means.

Unfortunately the keyboard revamp isn't going to change this. I have an experimental branch now that updates tcell to the latest v3 version, and it doesn't change anything about the Ctrl-J issue in MinTTY.