[Lldb-commits] [lldb] [lldb] Correctly restore the cursor column after resizing the statusline (PR #145823)

[Jonas Devlieghere via lldb-commits]

JDevlieghere wrote:

> That's true, but it kind of relies on editline not moving the cursor between the time we ask for the location and when we do the statusline dance. In that sense, the hammer approach would be more robust as it would presumably happen while holding the editline mutex. I guess that would be fine in most cases because changing the setting is usually triggered by a CLI command, and that should complete before we start processing the next command... Though, if that's the case, then I'm confused why isn't this working already, and if we couldn't just reorder a couple of calls to make sure the status line is drawn before the prompt.

Holding the  editline mutex is a compelling argument for the hammer approach. For completeness, the other reasons I didn't go with this approach were that we already call back from Editline to redraw the statusline after it has done something to clear the screen so you'd get a dance where editline asks the statusline to redraw which asks editline to redraw the prompt. 

I'll take a look and see what it would take to create a function in Editline that can "redraw the prompt" safely. The `MoveCursor` function takes an argument that tells it where the cursor is (i.e. `EditingCursor`, `EditingPrompt`, `BlockEnd`) based on where it's called from. I'll need to make sure this behaves correctly when called "asynchronously". 

> Going back to my list of bad ideas, I think I now know why the first one doesn't work (because we don't know whether `\n'` will scroll the window -- it will only do that if we're at the last line), but here's bad idea number four: What if we just _always_ scroll the window -- instead of `\n` we do a `Scroll Up(1)`? Could we then do the dance with saving the cursor location? I guess it would mean that we lose one line of visible output in the case where it would not be necessary to scroll (cursor not at last line), but maybe that's not such a bad thing?

I had considered this but I quickly discarded it after trying it because it looks like very much like a bug. When you interactive resize the terminal we'll get a bunch of `SIGWINCH`s (which is desirable because otherwise text might have wrapped and we don't get a chance to clear it, which is another bug...) so your text would scroll up every time the number of terminal rows changes, which can be a lot.

https://github.com/llvm/llvm-project/pull/145823