Marc Lehmann wrote: > "fixing" this clearly undesirable behaviour is not that easy, as its > not clear what the correct behaviour should be in all cases, and how to > implement it (in fact, there are a number of incompatible behaviours that > actually are desirable, so this might end up being one or two optionsa).
Are there any situations where scrolling in blank space from before the start of the scrollback buffer is actually desirable? Shouldn't that point be a hard limit. That could mean that you might need to handle a window enlargement by first pulling in the scrollback buffer at the top AND adding blanks to the bottom if there wasn't enough lines of scrollback available to cover the required extra lines. > The line containing the text that the cursor was in before resize should > be the line that the cursor is after resize (which might be somewhere else > in the window after the resize). > > > >From what I can see what doesn't change on resize is the number of > > lines after the prompt, not before the prompt. > > > > Can you also describe one of these readline issues in a way that I > > could reproduce it? > > When the cursor moves to a different line and readline redraws its prompt it > wilkl splatter prompts all over the terminal on resize. Whether lines are scrolled in from the top or bottom isn't moving the cursor relative to the text. It might change the cursor's coordinates. Surely readline expects absolute coordinates to be invalid after receiving SIGWINCH? The relative coordinates between the cursor and the prompt would seem more difficult, especially if you reduce the width to wrap the line containing the cursor. Testing resizes with readline, it still easily creates a mess. Zsh seems to fair rather better - at worst the text gradually scrolls up until only the current line remains. Oliver _______________________________________________ rxvt-unicode mailing list rxvt-unicode@lists.schmorp.de http://lists.schmorp.de/mailman/listinfo/rxvt-unicode
