Fix rendering of CRLF sequence ('\r\n') #98
Merged
Conversation
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
The FirstGraphemeCluster call returns this as a single character; we want to treat it the same way as a single \n. This would be a problem if e.g. a progress bar used \r repeatedly to paint over the same line, and then printed a \n to move on to the next line; the last pair of \r and \n was swallowed. Another scenario where this was a problem was if you stream output of a command to the log, and the command used \r\n as line feeds. This happens for example for a background fetch that fails with an error; in that case we print the combined output (stdout plus stderr) to the log after the command finished, and for some reason it uses \r\n in that case (I can't actually explain why; when I do `git fetch --all | xxd` I see only bare \n characters). All output would appear on one line then.
stefanhaller
added a commit
to jesseduffield/lazygit
that referenced
this pull request
Jan 25, 2026
This brings in jesseduffield/gocui#98 with the following fix: Fix rendering of CRLF sequence ('\r\n') The FirstGraphemeCluster call returns this as a single character; we want to treat it the same way as a single \n. This would be a problem if e.g. a progress bar used \r repeatedly to paint over the same line, and then printed a \n to move on to the next line; the last pair of \r and \n was swallowed. Another scenario where this was a problem was if you stream output of a command to the log, and the command used \r\n as line feeds. This happens for example for a background fetch that fails with an error; in that case we print the combined output (stdout plus stderr) to the log after the command finished, and for some reason it uses \r\n in that case (I can't actually explain why; when I do `git fetch --all | xxd` I see only bare \n characters). All output would appear on one line then.
The escape sequences `ESC ( ...`, `ESC ) ...`, `ESC * ...`, and `ESC + ...` are all character set designation sequences (or G-set designations). There's nothing useful we can do with them, so we just skip them. In practice, the only one that you are likely to see is `ESC ( B`, which is sent as part of `tput sgr0`, which is sometimes used in scripts to reset all graphics attributes to defaults.
stefanhaller
added a commit
to jesseduffield/lazygit
that referenced
this pull request
Jan 26, 2026
This brings in jesseduffield/gocui#98 with the following fix: Fix rendering of CRLF sequence ('\r\n') The FirstGraphemeCluster call returns this as a single character; we want to treat it the same way as a single \n. This would be a problem if e.g. a progress bar used \r repeatedly to paint over the same line, and then printed a \n to move on to the next line; the last pair of \r and \n was swallowed. Another scenario where this was a problem was if you stream output of a command to the log, and the command used \r\n as line feeds. This happens for example for a background fetch that fails with an error; in that case we print the combined output (stdout plus stderr) to the log after the command finished, and for some reason it uses \r\n in that case (I can't actually explain why; when I do `git fetch --all | xxd` I see only bare \n characters). All output would appear on one line then.
stefanhaller
added a commit
to jesseduffield/lazygit
that referenced
this pull request
Jan 28, 2026
This brings in jesseduffield/gocui#98 with the following fix: Fix rendering of CRLF sequence ('\r\n') The FirstGraphemeCluster call returns this as a single character; we want to treat it the same way as a single \n. This would be a problem if e.g. a progress bar used \r repeatedly to paint over the same line, and then printed a \n to move on to the next line; the last pair of \r and \n was swallowed. Another scenario where this was a problem was if you stream output of a command to the log, and the command used \r\n as line feeds. This happens for example for a background fetch that fails with an error; in that case we print the combined output (stdout plus stderr) to the log after the command finished, and for some reason it uses \r\n in that case (I can't actually explain why; when I do `git fetch --all | xxd` I see only bare \n characters). All output would appear on one line then. Also, filter out escape sequences for character set designation; there's nothing useful we can do with them. In practice, the only one that you are likely to see is `ESC ( B`, which is sent as part of tput sgr0, which is sometimes used in scripts to reset all graphics attributes to defaults.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
The FirstGraphemeCluster call returns this as a single character; we want to treat it the same way as a single \n.
This would be a problem if e.g. a progress bar used \r repeatedly to paint over the same line, and then printed a \n to move on to the next line; the last pair of \r and \n was swallowed.
Another scenario where this was a problem was if you stream output of a command to the log, and the command used \r\n as line feeds. This happens for example for a background fetch that fails with an error; in that case we print the combined output (stdout plus stderr) to the log after the command finished, and for some reason it uses \r\n in that case (I can't actually explain why; when I do
git fetch --all | xxdI see only bare \n characters). All output would appear on one line then.Also, filter out escape sequences for character set designation; there's nothing useful we can do with them. In practice, the only one that you are likely to see is
ESC ( B, which is sent as part oftput sgr0, which is sometimes used in scripts to reset all graphics attributes to defaults.