[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
padscroll.c
Description: Text Data
signature.asc
Description: PGP signature