JDevlieghere wrote: > This PR uses the active IOHanlder (which is Editline), but you're saying that > prior to this PR, Editline was sometimes able to recover. So we were using > Editline all along? Confused as to what is Editline the library and what is > our Editline code. > I am confused which bits are handled by editline the library and which are > handled by our code that interacts with editline, but I always have been so > that shouldn't block this :)
I didn't quite get what was causing the confusion so thanks for clarifying. 1. The bug is always there: when reducing the scroll window (on launch or when resizing the terminal) the statusline always leaves the cursor at the wrong column. 2. The bug isn't always observable: when Editline (re)draws the prompt after we left the cursor in the wrong spot it looks like things behave correctly, even though they don't. The bug is there but it's obscured. 3. When you hit the bug, you can recover from it by typing something. This is what I meant when I said that "Editline is able to recover from this". The challenge is that there is no escape code to move the cursor to its correct location, at least not without knowing what that location is. I was intrigued by the fact that Editline seemingly was able to do that anyway, so I wanted to understand how (2) and especially (3). The former could have been explained by just redrawing the prompt, but I noticed that if your cursor was't right at the end of the prompt, (3) would still do the right thing. The answer was that `Editline::MoveCursor` is using the `LineInfo` struct to get the index of the cursor and the length of the buffer, which allows you to compute the position of the cursor on the current line. In other words, when Editline was redrawing the cursor, it was calling `Editline::MoveCursor` to move the cursor to the correct position. One solution could have been to indirectly rely on this behavior and ask our Editline wrapper to redraw the prompt or something after we change the scroll window. That's essentially was @labath suggested in https://github.com/llvm/llvm-project/issues/134064#issuecomment-2929542360. However that's overkill: instead of using a hammer and redraw the whole thing, we can use the same information (the `LineInfo` struct in Editline) to figure out the correct column position. That's what this patch does: it queried the IOHandler (Editline) for the cursor column position before we much with it, and then uses that to move the cursor to that exact location. In other words, we're using the same information that Editline uses to move the cursor to the correct position when drawign the statusline. But we're doing it without having Editline do that for us. 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
