Scroll half page up / down does not redraw half screen

[erf]

When opening a file which is longer than the viewport and pressing Ctrl-d and (sometimes Ctrl-u) to scroll the view down / up, only half the page is redrawn, the rest is the same. I believe this is something that has occured in recent changes.

I've build from source on commit "de315f8", on macos

[rnpnr]

I'm not able to recreate. I tried both with and without curses enabled. Did you try with the default config file?

[erf]

It's the same when i remove my visrc.lua file.

Here is a screen recording: https://github.com/martanne/vis/assets/1562523/9be16af5-776c-4933-9d35-5c8737e224d9

Here is the output from the configure call:

~/projects/vis % ./configure 
checking for C compiler... cc
checking whether C compiler works... yes
checking whether compiler accepts -Werror=unknown-warning-option... yes
checking whether compiler accepts -Werror=unused-command-line-argument... yes
checking whether linker accepts -Werror=unknown-warning-option... no
checking whether linker accepts -Werror=unused-command-line-argument... no
checking whether compiler accepts -pipe... yes
checking whether compiler accepts -O2... yes
checking whether compiler accepts -ffunction-sections... yes
checking whether compiler accepts -fdata-sections... yes
checking whether linker accepts -Wl,--gc-sections... no
checking whether compiler accepts -fPIE... yes
checking whether compiler accepts -fstack-protector-all... yes
checking whether linker accepts -Wl,-z,now... no
checking whether linker accepts -Wl,-z,relro... no
checking whether linker accepts -pie... no
creating config.mk... done
checking for pkg-config... yes
checking for libcurses...
 checking for ncursesw... yes
checking for libtermkey... yes
checking for libtre... yes
checking for liblua >= 5.2 ...
 checking for lua... yes
checking for Lua statically linked liblpeg...
 checking for static lpeg... no
 checking for static lua5.3-lpeg... no
 checking for static lua5.2-lpeg... no
checking for memrchr... no
completing config.mk... done

Tested with both Wezterm, iTerm2, and Terminal

[rnpnr]

Nothing looks wrong in the configure.

Can I ask you to do a git-bisect? My best guess for commits that could be causing this would be 5d7d62c or d1f2c27. So I would probably check that 7cc6fcc doesn't have the issue and then start from there.

[erf]

That's really weird. I tried to go all the way back to that v0.7.1 tag, but still the same issue. Must be some other cause.

[rnpnr]

Interesting, the only other thing I can think of trying is building with --disable-curses. Its possible that there was curses update or something on macOS. I'm just not sure I can think of anything else that would describe you seeing this issue in all those terminal emulators, I think they are all using their own rendering methods.

If that doesn't describe it I guess we jut leave this open and see if anyone else runs into the problem.

[erf]

If i run configure --disable-curse it worked, so something seemed to have happened with my curses. I added the homebrew version of ncurses to PATH in .zshrc, and that seemed to solve the issue.

As a side note .. would the vt100 backend be enough ? performance and functionality wise, if we limit ourselves to a set of escape codes supported on a limited set of systems we support.

[rnpnr]

would the vt100 backend be enough

For the longest time that was all I ever used with vis. I only started using the curses backend to test patches. Maybe there are some additional curses features that I don't know about but I never noticed a difference.