wezterm terminfo leads to corrupted buffer text when scrolling in zellij + neovim vertical split

[CarbonChauvinist]

What Operating System(s) are you seeing this problem on?

Linux Wayland

Which Wayland compositor or X11 Window manager(s) are you using?

Mutter + Zellij

WezTerm version

20240203-110809-5046fc22

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

When setting term = wezterm in config and using Zellij as multiplexer if one creates a vertical split in neovim scrolling in one buffer causes the other buffer's text to become garbled and corrupted and eventually disappear.

I realize there are a lot of potential culprits here and I've tried as best I can to isolate what may be contributing the unexpected behavior. To wit, not setting the term to wezterm and instead using the default xterm-256color does not cause the reported issue in Zellij + neovim. In fact Wezterm with wezterm terminfo without Zellij does not cause the reported behavior. My impression is that this may have something to do with the wezterm terminfo and how it interacts with Zellij and/or neovim. What gives me hope that it may be able to be addressed is that foot for instance has it's own custom terminfo foot-extra that works as expected with Zellij + neovim.

So far, I've tested the following terminals with the listed TERM settings and also did not experience the corrupted buffer text.

The terminals I tested where the issue did not present itself: (terminal/TERM)

• Foot with foot-extra TERM env var
• Sakura with xterm-256color TERM env var
• Kitty with xterm-kitty env var
• Wezterm with xterm-256color TERM env var

To Reproduce

To reproduce:

1. run wezterm with term set to wezterm in config
2. run zellij with default settings.
3. run development version of neovim also in a clean state with no plugins loaded (i.e. nvim --clean -u NONE -i NONE)
4. open any file
5. create a vertical split
6. scroll down in the current window and observe the reported issue in the neighboring window within neovim

Attached a short screen capture of the behavior for reference.

zellij_neovim_vertical_split_scroll_issues.mp4

Also note, in Wezterm with wezterm TERM env this issue does not present itself when running latest version of vim available in the standard Arch repos, nor does it present itself when running neovim without zellij.

Configuration

local wezterm = require("wezterm")
local mux = wezterm.mux

wezterm.on("gui-startup", function(cmd)
  local tab, pane, window = mux.spawn_window(cmd or {})
  window:gui_window():toggle_fullscreen()
end)

return {
  font = wezterm.font_with_fallback({
    "Jet Brains Mono",
    "Noto Sans Symbols2",
  }),
  term = "wezterm",
  enable_wayland = true,
  hide_tab_bar_if_only_one_tab = true,
  default_cursor_style = "BlinkingBlock",
  window_padding = {
    left = 0,
    right = 0,
    top = 0,
    bottom = 0,
  },
  window_background_opacity = 1.0,
  color_scheme = "selenized",
}

Expected Behavior

Scrolling in wezterm + zellij + neovim vertically split window does not corrupt text in opposite buffer.

Logs

Attached is output from WEZTERM_LOG=wezterm_gui=debug,info wezterm >> log_file.txt 2>&1 (because otherwise debug for all modules is a huge file/output)
log_file.txt

Anything else?

No response

[vpunch]

I have the same problem

[tmccombs]

I have the same problem. But I can reproduce with just neovim, no need for zellij. See my comment at neovim/neovim#17142 (comment).

I can reproduce with the following steps:

1. Start wezterm with minimal config: wezterm -n --config 'term="wezterm"'
2. In wezterm terminal run nvim -u NORC <file with lots of lines>
3. Create a vertical split (<C-W>V)
4. Change focus to window on the right (<C-W>L)
5. Move cursor to bottom (L)
6. Scroll down (repeated "j")
7. Observe tearing in window on the left.

Kooha-2024-07-22-23-26-37.webm

Neovim version: 0.10.0
wezterm version: 20240203-110809-5046fc22
OS: archlinux

[tmccombs]

Since this problem doesn't happen if TERM is set to xterm-256color, my guess is that it is an issue with the terminfo entry for wezterm.

[j4james]

@tmccombs I don't know if this covers all the problems reported in this issue, but your particular case is probably caused by the code here:

wezterm/term/src/terminalstate/mod.rs

Lines 2317 to 2321 in 7e8fdc1

	if self.left_and_right_margin_mode {
	let rows = self.screen().physical_rows as u32;
	let cols = self.screen().physical_cols as u32;
	let left = left.as_zero_based().min(rows - 1).max(0) as usize;
	let right = right.as_zero_based().min(cols - 1).max(0) as usize;

Note that the left margin is incorrect clamped to the height of the display rather than the width. So when your screen height is 23 rows, the maximum width of the left half of a split is 23, and that's why only the first 23 columns remain static when you're scrolling the right hand side.

[arusahni]

@tmccombs I recently encountered that issue, too. In my case, I didn't have the term definition installed on my machine. I followed the steps here and the glitching was resolved.

[tmccombs]

Hmmm, so I did have a terminfo entry for wezterm installed as part of the ncurses package (a wezterm terminfo entry was added in 6.5). But that entry seems to be different from the entry I get from the instructions for installing it locally.

If I do follow those instructions it seems to fix the issue.

If I use infocmp to compare the terminfo entries from ncurses, and the wezterm source respectively, I get the following differences:

❯ infocmp -d -A /usr/share/terminfo -B ~/.terminfo wezterm
comparing wezterm to wezterm.
    comparing booleans.
        hs: F:T.
        km: F:T.
        xenl: F:T.
    comparing numbers.
        pairs: 65536, 32767.
    comparing strings.
        cvvis: NULL, '\E[?12;25h'.
        dsl: NULL, '\E]2;\E\\'.
        fsl: NULL, '\E\\'.
        ka1: '\EOw', NULL.
        ka3: '\EOy', NULL.
        kb2: '\EOu', '\EOE'.
        kbeg: '\EOE', NULL.
        kc1: '\EOq', NULL.
        kc3: '\EOs', NULL.
        mgc: '\E[?69l', NULL.
        nel: '\EE', NULL.
        rmkx: '\E[?1l', '\E[?1l\E>'.
        rmm: NULL, '\E[?1034l'.
        smglp: '\E[?69h\E[%i%p1%ds', NULL.
        smglr: '\E[?69h\E[%i%p1%d;%p2%ds', NULL.
        smgrp: '\E[?69h\E[%i;%p1%ds', NULL.
        smkx: '\E[?1h', '\E[?1h\E='.
        smm: NULL, '\E[?1034h'.
        tsl: NULL, '\E]0;'.

So maybe a bug should be reported to ncurses? I'm willing to do it, but it might be better if someone more familiar with terminfo databases and/or a member of the wezterm project is at least included in the conversation.

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.