Cherrypick upstream statusline resizing commits #10956
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
(cherry picked from commit caaca32)
I can't find a proper source for this but many materials say that ANSI rows and columns start at 1 not 0. https://www2.math.upenn.edu/~kazdan/210/computer/ansi.html is as good as I can get: ``` <row> is a number from 1 through 25 that specifies the row to which the cursor is to be moved. <col> is a number from 1 through 80 that specifies the column to which the cursor is to be moved. ``` 0 does work in Windows terminal and Linux terminals, but we might as well be correct and it's one less thing to reason about when auditing this code. From what I read, some terminals correct 0 back to 1 and some treat 0 as a missing argument, which also defaults to 1. (cherry picked from commit 6ec48b4)
…ine (llvm#146132) This PR ensures we correctly restore the cursor column after resizing the statusline. To ensure we have space for the statusline, we have to emit a newline to move up everything on screen. The newline causes the cursor to move to the start of the next line, which needs to be undone. Normally, we would use escape codes to save & restore the cursor position, but that doesn't work here, as the cursor position may have (purposely) changed. Instead, we move the cursor up one line using an escape code, but we weren't restoring the column. Interestingly, Editline was able to recover from this issue through the LineInfo struct which contains the buffer and the cursor location, which allows us to compute the column. This PR addresses the bug by having Editline "refresh" the cursor position. Fixes llvm#134064 (cherry picked from commit 1eb7954)
Letting Editline refresh itself is more robust and ensures that the current text is redraw if it was accidentally cleared. In that scenario MoveCursor would only fix up the cursor position. (cherry picked from commit 3edae0d)
…146578) Terminal resizing continues to be a source of statusline bugs, so much so that some users have started disabling it altogether. Different operating systems and terminal emulators exhibit subtly different behaviors, making it nearly impossible to handle resizing reliably across the board. This patch sidesteps those issues by clearing the entire screen when the terminal is resized. This avoids having to account for the previous, potentially wrapped statusline, the underlying cause of many of the aforementioned bugs. The obvious downside is that this clears the on-screen history, but I believe that’s a reasonable trade-off. Note that this only happens when resizing the terminal; when launching LLDB, the statusline is drawn without clearing the screen. rdar://154778410 (cherry picked from commit 2f75f65)
adrian-prantl
approved these changes
Jul 3, 2025
|
@swift-ci test |
|
@swift-ci test macos |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 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.
rdar://154778410