request explicit return from subprocess#454
Merged
Merged
Conversation
Previously we were recording output from subprocesses using a multiwriter and hooking that up to the cmd's stdout to write to both os.Stdout and a buffer. We would then display the output after the program finished. This worked well for commands like 'ls' but not for commands like 'vi' which expect you to be in a tty, and when you've got the cmd's stdout pointing at a multiwriter, the subprogram thinks we're not in a tty and then things like terminal corruption can happen. This was the case with neovim, and even in vim a warning was given with a pause before starting the program. Now we're chucking out the multiwriter and instead making it that you need to press enter after the program has finished to return to lazygit. This allows you to view the output of the program (e.g. if it's ls) and then decide that you want to return. It's one level of unnecessary redirection for editors like vim, but even they could potentially have output to stderr/stdout that you want to look at before returning. Please enter the commit message for your changes. Lines starting
jesseduffield
force-pushed
the
437_output_from_subprocess
branch
from
May 26, 2019 01:34
03299e2 to
e0aa982
Compare
Codecov Report
@@ Coverage Diff @@
## master #454 +/- ##
==========================================
+ Coverage 84.89% 84.93% +0.03%
==========================================
Files 21 21
Lines 3542 3551 +9
==========================================
+ Hits 3007 3016 +9
Misses 493 493
Partials 42 42
Continue to review full report at Codecov.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Previously we were recording output from subprocesses using a multiwriter
and hooking that up to the cmd's stdout to write to both os.Stdout and
a buffer. We would then display the output after the program finished.
This worked well for commands like 'ls' but not for commands like 'vi'
which expect you to be in a tty, and when you've got the cmd's stdout
pointing at a multiwriter, the subprogram thinks we're not in a tty
and then things like terminal corruption can happen. This was the case
with neovim, and even in vim a warning was given with a pause before
starting the program.
Now we're chucking out the multiwriter and instead making it that you
need to press enter after the program has finished to return to lazygit.
This allows you to view the output of the program (e.g. if it's ls) and
then decide that you want to return. It's one level of unnecessary
redirection for editors like vim, but even they could potentially have
output to stderr/stdout that you want to look at before returning.