On Tue, Jun 06, 2023 at 05:02:44PM +0200, Oliver Kiddle <[email protected]>
wrote:
> Are there any situations where scrolling in blank space from before the
> start of the scrollback buffer is actually desirable?
Yes, I personally prefer it that way, but the occasions where this matter
to me were so rare that I never bothered looking into it. The initial
resize behaviour, on the other hand, was often a topic, as some users
would prefer their prompt to always be on the bottom, some applications
have trouble with urxvts resizing algorithm and heuristic (which depends
on scrollback), and so on. Thus having a set of options is probably the
way to go (thus the recewnt introduction of rewrapMode, which had a bug
whose fix actually caused the behaviour change).
> > 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.
Not sure I follow, but moving it relative to the text is a goal that has
been implemented in the current version, but wasn't the case in older
versions.
> Surely readline expects absolute coordinates to be invalid after
> receiving SIGWINCH?
readline has no notion of absolute coordinates, afaik. it's not a
full-screen application such as apps based on curses. it hardcodes a lot of
assumpotions of how trerminals behave in corner cases.
> 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.
Without doubt, not everything is perfect in readline-land as well.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / [email protected]
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
rxvt-unicode mailing list
[email protected]
http://lists.schmorp.de/mailman/listinfo/rxvt-unicode
