Re: ripoffline() behavior with resizable windows

[Bill Gray]

Hi Thomas,  all,

On 10/2/23 04:08, Thomas Dickey wrote:
> but the documentation for ripoffline doesn't directly mention soft-keys,

   Hmmm... I made the connection based on :

https://invisible-island.net/ncurses/man/curs_kernel.3x.html

    "...The ripoffline routine  provides access to the same
   facility  that slk_init  [see  curs_slk(3x)] uses to reduce
   the size of the screen."

   Supporting this is the fact that if you have SLK plus four ripped-off lines, 
 such as

./ripoff s1 b b t b

   ("set up SLK,  rip two lines off the bottom,  one from the top,  and another from the 
bottom"),  it works.  Add another t or b,  and you get the "Only five lines can be ripped 
off" error message.  Try it again without the 's1' (with just five ripped-off lines),  and it 
works... it really looks as if the SLK line is considered as one of the ripped-off lines.

   (Interestingly,  if you use s3 -- the format with an index line added -- it 
appears to count as only one ripped-off line.  Presumably,  there's just one 
window created that is two lines high.)

> and is explicit that it's called only once.

   I was afraid of that,  but wasn't too clear on it from the text cited above.
> > https://www.projectpluto.com/temp/ripoff.c
> >
> >     Compile and run as,  for example,
> >
> > ./ripoff b b t
> >
> >     ("rip off two lines at the bottom,  then one at the top"),  resize
> > horizontally,  and you'll see what I mean.  In particular,  if you shrink
> > the window horizontally and re-expand,  you lose the text in the columns you
> > shrank over.
>
> I don't see any text lost (in xterm, of course).  It is repainted.

   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.

> >     It seems to me as if the callback function should be called (at least) in
> > situations where COLS changes : in initscr( ) and whenever the screen is
> > resized horizontally.  Does this make sense to you?
>
> perhaps as a new function, but not really for the existing function.

   Given the need for backward compatibility,  I'd have to agree.  The best we 
can do is to ensure that if the screen is resized to be smaller horizontally,  
then restored,  we don't lose columns.

Thanks!         -- Bill