Re: ripoffline() behavior with resizable windows

[Bill Gray]

On 10/3/23 19:46, Thomas Dickey wrote:>>     Hmmm... that's quite 
puzzling.  If I start in (say) an 80x25 column xterm,  the ripped-off 
lines are shown properly.  If I expand to (say) 84 columns,  each line 
has four blanks at the end,  as could somewhat be expected.
> >     If I then shrink to (say) 77 columns and then return to 80,  the last three 
> > columns are wiped out.
>
> I'm using the E/e options in the ncurses test-program -
> there may be some logic for repainting that I'm forgetting,
> but that program doesn't lose any text. >
> Retesting with your sample program, I get the same result - if
> I shrink the screen so that there's not enough room, then the
> labels are hidden until I restore the screen-width.
>   
   Ah,  sorry,  I wasn't as clear as I should have been.  I don't see 
any issues with the SLK lines (in either ncurses or PDCursesMod).  The 
problems only occur with "other",  non-SLK ripped-off lines.  If you run 
my test code as,  say,

./ripoff s1 b t b

   and then do the resizing,  the SLK labels do indeed redraw properly. 
 But the other two ripped-off lines at the bottom and the one at the 
top don't : when the screen shrinks horizontally,  the 'lost' columns 
stay that way when it's expanded.

   Incidentally,  another (slightly) odd bit : if you rearrange the 
command-line arguments to read

./ripoff b s1 b t

   then the SLK labels appear in between the two ripped-from-the-bottom 
lines :

https://projectpluto.com/temp/z.png

   Which actually makes sense to me,  since the SLK labels are just 
re-using the ripped-off-line functionality.

-- Bill