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 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
