Lazygit: Terminal corruption when opening editor

[Odaeus]

Describe the bug
I've been using the lazygit Ubuntu package which I think is automatically derived from master on a daily basis. This bug does not affect the latest 0.7.2 release.

Since an update a week or so ago, opening the external editor (Nvim for me) to write a commit message results in display corruption. Input is still accepted but displayed literally on the screen.

To Reproduce
Steps to reproduce the behavior:

1. Press C to make commit with external editor.

Expected behavior
Am able to edit commits as before.

Screenshots

The black area is the rest of my terminal. The nvim window has been reduced in size to the top left corner. The grey characters on the second line are my input from pressing arrow keys or the mouse. I have blurred out potentially sensitive information, that's not a bug 😉.

Desktop:

• OS: Ubuntu Linux 4.18.0 x86_64
• Lazygit Version: 0.0\~git20190413.458.cadc74e-1~ubuntu18.10.1 (from APT)

Additional context

• I use the latest Nvim.
• The session is within Tmux, connected over SSH with iTerm on Mac.
• I uninstalled the package and installed the 0.7.2 lazygit binary from GitHub and that works fine.

[mjarkk]

Same problem here neovim doesn't seem to work nicely together with lg.

Desktop:

• Version: latest master
• OS: Solus 4
• Terminal Emulator: alacritty and gnome-terminal

Aditional context

• a normal git commit works fine with neovim
• editing the lg config from lg also breaks noevim (status pannel > e)
• vi and vim have no problems running from lazygit
• alacritty has the same resize bug shown above, the gnome-terminal resizes as expected but the neovim input is still broken

[jack828]

I am also experiencing this issue, Ubuntu Budgie 18.04, Lazygit 0.0~git20190426.464.b505c29-1~ubuntu18.04.1, using Kitty terminal emulator. Running the commit command within a TMUX session, as well.

[ybbond]

previously, I can open file (keybinding e) and edit commit message (keybinding C) when I first install lazygit at April 25th (v06)

after I updated to latest yesterday, it went error. Just like Author's case

• Version: Lazygit v08
• OS: MacOS 10.14
• Terminal Emulator: Kitty (without tmux)
• EDITOR set as neovim's nightly build

[jesseduffield]

I've just done some investigation, and it turns out that this bug was introduced when we added support for calling custom commands. When we switch to a subprocess, instead of saying cmd.Stdout = os.Stdout, we're now saying cmd.Stdout = io.MultiWriter(os.Stdout, &stdoutBuf), so that after the program has run we can report back the output of the program within lazygit (ironically we don't show the output for programs like neovim because it's so many characters).

Based on my reading of this thread https://stackoverflow.com/questions/33452726/golang-difference-between-os-stdout-and-multiwriter it seems that neovim is using something like isatty under the hood to decide whether to output in the context of a tty or not, and using the multiwriter makes it think we're no longer in a tty.

I'm not quite sure what the workaround is here. I don't particularly like the idea of creating a whitelist of programs to not use a multiwriter with, given the complexity cost, but I'm not sure how to get neovim to format things as if it was an a tty.

I am open to suggestions :)

[jesseduffield]

relevant PR: https://github.com/neovim/neovim/pull/7679

[jesseduffield]

seems like running nvim -es should allow us to use a multiwriter but it just fails immediately when I set:

[core]
    editor = nvim -es

in the global gitconfig

[kristijanhusak]

@jesseduffield i just tried that but unfortunately it doesn't work for me. When i tried to edit a file UI just blinks. Like something happens in the background and it comes back where it was.
When i try to commit i get Aborting commit due to empty commit message. error.

Looks like something is executed twice or something like that.

[Odaeus]

It seems like the problem is that there is a valid fundamental difference between launching an interactive program and one that only writes output? I'm not sure it's possible to have a single "this is an external process" launcher. Is it reasonable to use the original code path for commands that open an editor and the MultiWriter when you want the output? I mean, there's no valid output from the editor to capture anyway is there?

[jesseduffield]

@Odaeus I've had a think about this and I think the right solution is to, instead of trying to record output as the subprocess runs, allow everything to be written to stdout, and then when the subprocess finishes, prompt the user to explicitly return to lazygit (by pressing the enter key). This means that for programs like 'ls', you can view the output, then decide to return.

Arguably that's a better experience overall, because you aren't viewing the output in a cramped popup box from within lazygit. The only downside is an additional bit of friction when it comes to e.g. writing commit messages. But another upside is that we can display the original command so you've got more context about what's going on under the hood:

I've put up a PR for this here https://github.com/jesseduffield/lazygit/pull/454

[jesseduffield]

I'm closing this issue because I've merged that PR but let me know if you think the solution can be improved :)

[kristijanhusak]

@jesseduffield it's working fine for me, thanks!

[jack828]

Can also confirm this is fixed for me, from apt - thanks!