[Bug]: Broken terminfo handling(?) in Neovim 0.12.1 leads to artifacting when using vertical splits

[Sw3d15h-F1s4]

Problem description

When you attempt to vertically scroll a split or insert a new line while two or more splits are visible, strange things occur. Vertically scrolling in one split causes all text on the screen to scroll down without actually scrolling anything - it's a purely visual bug. Press Control+L to force a redraw and see nothing on the other split changed.
Inserting a new line creates gaps in the other split, again redrawing shows this is just a visual bug.

I'm a naive idiot, but my guess is something changed with how Neovim sends scrolling escape characters and Termux doesn't handle it right.

What steps will reproduce the bug?

• Install neovim v0.12.1 and do nvim --clean.
• Open any file that you need to vertically scroll through.
• Open a vertical split by doing :vs. Scroll one of the splits down
• Observe the other split scroll down anyway
• Temporarily resolve the issue by pressing <C-l> (Control+L)

OR

• Install neovim v0.12.1 and do nvim --clean.
• Put a few lines of text on the screen.
• do :vs
• Move to a line with some text above and below. Insert a new line by pressing o
• Observe the other split.
• Temporarily resolve the issue by pressing <C-l> (Control+L)

What is the expected behavior?

Last version I tried was neovim v0.11.6, which worked fine.

System information

Termux Variables:
TERMUX_APK_RELEASE=F_DROID
TERMUX_APP_PACKAGE_MANAGER=apt
TERMUX_APP_PID=16386
TERMUX_APP__DATA_DIR=/data/user/0/com.termux
TERMUX_APP__LEGACY_DATA_DIR=/data/data/com.termux
TERMUX_APP__SE_FILE_CONTEXT=u:object_r:app_data_file:s0:c123,c257,c512,c768
TERMUX_APP__SE_INFO=default:targetSdkVersion=28:complete
TERMUX_IS_DEBUGGABLE_BUILD=0
TERMUX_MAIN_PACKAGE_FORMAT=debian
TERMUX_VERSION=0.118.3
TERMUX__HOME=/data/data/com.termux/files/home
TERMUX__PREFIX=/data/data/com.termux/files/usr
TERMUX__ROOTFS_DIR=/data/data/com.termux/files
TERMUX__SE_PROCESS_CONTEXT=u®untrusted_app_27:s0:c123,c257,c512,c768
TERMUX__USER_ID=0
Packages CPU architecture:
aarch64
Subscribed repositories:
# sources.list
deb https://termux.danyael.xyz/termux/termux-main stable main
Updatable packages:
All packages up to date
termux-tools version:
1.45.0
Android version:
14
Kernel build information:
Linux localhost 5.4.254-qgki-28692233-abT733XXS9DYF1 #1 SMP PREEMPT Thu Jun 19 22:10:26 KST 2025 aarch64 Android
Device manufacturer:
samsung
Device model:
SM-T733
Supported ABIs:
SUPPORTED_ABIS: arm64-v8a,armeabi-v7a,armeabi
SUPPORTED_32_BIT_ABIS: armeabi-v7a,armeabi
SUPPORTED_64_BIT_ABIS: arm64-v8a
LD Variables:
LD_LIBRARY_PATH=
LD_PRELOAD=/data/data/com.termux/files/usr/lib/libtermux-exec-ld-preload.so
Installed termux plugins:
com.termux.widget versionCode:1001
com.termux.x11 versionCode:15
com.termux.gui versionCode:7
com.termux.window versionCode:1001
com.termux.styling versionCode:1000
com.termux.boot versionCode:1000

[Sw3d15h-F1s4]

I'm not 100% sure if this is a neovim problem, a termux problem, or both. It's worth noting I can't reproduce this issue on my Linux (non-android, ofc) desktop.

[TomJo2000]

Vertically scrolling in one split causes all text on the screen to scroll down without actually scrolling anything - it's a purely visual bug.
[...]
Inserting a new line creates gaps in the other split, again redrawing shows this is just a visual bug.

I'm having a hard time picturing this so I might be getting a wrong impression here.
I just wanna clarify a few assumptions I've made based off this description.

• 1.) Both splits are opened to the same file since :vs with no args creates a new split showing the current buffer.
• 2.) Scrolling in one buffer scrolls both buffers?
  It is ambiguous to me from the description what sort of visual artifacts this causes.
  So the options as I see them are:
  • 2.1) Both buffers scroll but their viewport positions aren't synced so one buffer may scroll off the end of the file before the other one does which should show ~ symbols beyond the end of the file.
  • 2.2) Only the active buffer scrolls but the scrolling causes visual artifacts in the inactive buffer(s).
• 3.) Inserting a newline cause further related weirdness.
  This is equally ambiguous to me but does intuitively make sense to be related to the same cause.

I'm a naive idiot, but my guess is something changed with how Neovim sends scrolling escape characters and Termux doesn't handle it right.

What steps will reproduce the bug?

• Install neovim v0.12.1 and do nvim --clean.
• Open any file that you need to vertically scroll through.
• Open a vertical split by doing :vs. Scroll one of the splits down
• Observe the other split scroll down anyway
• Temporarily resolve the issue by pressing <C-l> (Control+L)

OR

• Install neovim v0.12.1 and do nvim --clean.
• Put a few lines of text on the screen.
• do :vs
• Move to a line with some text above and below. Insert a new line by pressing o
• Observe the other split.
• Temporarily resolve the issue by pressing <C-l> (Control+L)

No you're definitely onto something here.
Thank you for also providing a minimal reproducible example with nvim --clean.

What is the expected behavior?

Last version I tried was neovim v0.11.6, which worked fine.

"Worked fine" meaning each buffer scrolls independently and separate buffers on the same file don't influence each others viewports.
Changes made in the active buffer should also be visible in any inactive buffer of the same file if within its viewport.

System information

[...]

This all looks normal to me.
I'm gonna use this last section to ask a couple setup questions.
You already demonstrated that that it's replicable under nvim --clean;

• What shell are you running.
• What is your $TERM value set to.
• Are you running a multiplexer like tmux, screen or zellij.
• Have you tried replicating this issue outside of Termux's terminal emulator implementation?
  e.g. SSH-ing into Termux or in an X11 session.
  • If so what terminal emulator(s) did you use for testing that.

Closing notes:
I've not been able to replicate the issue over SSH (using Wezterm-nightly as the terminal emulator).
I can replicate the issue locally but I am not sure what I am looking at here.

The issue occurs both in vertical and horizontal orientation, but not with horizontal splits.

[Sw3d15h-F1s4]

Screen_Recording_20260414_011627_Termux.mp4

Ive taken a screen recording of what is going on, hopefully that illustrates how weird this is. its so strange haha.

As for your questions, I'm running fish 4.6.0, and i've been able to replicate the issue with bash 5.3.9(1)-release.
My $TERM is set to xterm-256color
I'm not running anything like tmux, zellij, or screen. Actually, using tmux, zellij, and screen FIXED the issue, there's normal behavior here.
Inside an x11 environment using termux-x11 :0 and dwm with st nvim works fine. In the meantime using nvim through tmux and sacrificing one row of the screen seems totally fine as a workaround for now

I'm suspecting something crazy with Termux itself.

[TomJo2000]

I can try bisecting this issue since it worked in 0.11.6.

But I suspect this might actually be an ncurses issue.
Changing the $TERM value seems to resolve the issue.
I tested with TERM=foot nvim --clean '+vs' packages/neovim/build.sh
foot's is one of the additional terminfo definitions we ship.
That fixed the issue.
But it also changed the default colorscheme of nvim --clean to something more blue which I'm not entirely sure is intended.

Here's a recording of the behavior on my device.

screen-20260414-085507.mp4

[TomJo2000]

I've updated the issue title to reflect what we've observed about the issue so far.
I'm also going to try replicating this in vim as a check for this being a Neovim regression or an Ncurses one.
If it's Neovim's regression then it shouldn't effect Vim.
If it's an Ncurses regression it may also effect Vim since the two still share a lot of code.

[TomJo2000]

It seems to be working as expected in Vim.
So this narrows it down to a regression within Neovim.

I can run a git bisect against the issue to try and track down the commit(s) responsible but that'll take a while.