labath 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.
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? 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
