bug-ncurses
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Possible bug with scrolling regions in pads?


From: Thomas Dickey
Subject: Re: Possible bug with scrolling regions in pads?
Date: Fri, 26 Jul 2019 04:39:09 -0400
User-agent: NeoMutt/20170113 (1.7.2)

On Thu, Jul 25, 2019 at 11:09:48PM -0500, Rob King wrote:
> Hello everyone,
> 
>     I think there may be a bug with pads and scrolling regions in
> ncurses-6.1 (and probably earlier versions too).

might be...

In a quick check (and modifying the example to c89), Solaris10 SVr4 curses
doesn't scroll the pad at all.  (Its X/Open curses dumps core, but that's
not unusual).
 
>     Take for example the following program (an adaptation of vttest's
> "accordion" test):
> 

By the way, it helps to send examples as attachments (since this came with
the leading blanks converted to nbsp's, it had to be massaged to compile).

>     wsetscrreg(pad, top_of_screen + 1, bottom_of_screen - 1);

Running this with a debug-trace, I see that the scrolling region is
using the pad's dimensions -- which extend outside the visible screen:

On a 24x80 screen, the limits do look odd:

        called {wsetscrreg(window0,25,46)
        return }0

...but I see that you're mapping it.

>     for (int i = 0; i < LINES + 10; i++){
>         wscrl(pad, i % 2? i : -i);
>         prefresh(pad, top_of_screen, 0, 0, 0, LINES - 1, COLS - 1);
>         sleep(1);
>     }
> 
>     sleep(10);
>     endwin();
> }
> 
> This program creates a pad taller than the screen, and treats the bottom
> part of the pad as the part that will get drawn to the screen. It then
> draws "TOP OF SCREEN" to the line in the pad that will be placed at the
> top of the physical screen, "BOTTOM OF SCREEN" at the bottom, and every
> other to-be-screen line with X's.
> 
> It then sets the scrolling region such that only the X's will scroll. It
> then calls wscrl with increasing positive and negative scrolling values.
> 
> When it is run, the X's bounce up and down as expected, losing a line
> each iteration. However, at the end, when the scrolling values get large
> enough, the lines outside the top and bottom of the scrolling region are
> scrolled away (the "TOP/BOTTOM OF SCREEN" lines). Given the value of the
> scrolling region, this shouldn't happen (unless I'm mistaken).

I see (will have to study this - made a to-do).

thanks

-- 
Thomas E. Dickey <address@hidden>
https://invisible-island.net
ftp://ftp.invisible-island.net

Attachment: padscroll.c
Description: Text Data

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]