Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Neovim vertical split redrawing bug #5488

Closed
b-jure opened this issue May 28, 2024 · 8 comments
Closed

Neovim vertical split redrawing bug #5488

b-jure opened this issue May 28, 2024 · 8 comments
Labels
bug Something isn't working

Comments

@b-jure
Copy link

b-jure commented May 28, 2024

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

Linux X11

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

i3

WezTerm version

20240520-135708-b8f94c47

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 in neovim vertical split, all of the panes to the left of the current pane are also scrolled up/down instead of only the active pane being scrolled (panes to the right are not affected). Additionally it scrolls always at the same margin, meaning the vertical line where this redraw bug occurs is always at the same fixed position. Focusing/moving to any pane after the bug redraws everything correctly.

To Reproduce

  1. Run wezterm terminal.
  2. Run nvim.
  3. Create a split vertical pane and move to the right pane.
  4. Open files in these panes and make sure the right pane buffer is scroll-able.
  5. Now scroll up/down the right buffer pane it should reproduce bug on the pane/s to the left.

Configuration

local wezterm = require("wezterm")
local config = wezterm.config_builder()

config.automatically_reload_config = true
config.disable_default_key_bindings = true
config.color_scheme = "Gruvbox Dark (Gogh)"
config.front_end = "OpenGL"
config.animation_fps = 1
config.cursor_blink_rate = 350
config.default_cursor_style = "BlinkingBlock"
config.hide_mouse_cursor_when_typing = true
config.tiling_desktop_environments = {
	"X11 i3",
	"X11 dwm",
}
config.window_decorations = "NONE"
config.default_prog = { "fish" }
config.enable_scroll_bar = false
config.enable_tab_bar = false
config.window_close_confirmation = "NeverPrompt"
config.term = "wezterm"
config.warn_about_missing_glyphs = false
config.font = wezterm.font_with_fallback({
	{ family = "Iosevka Custom", weight = "Medium" },
	{ family = "FiraCode Nerd Font" },
	{ family = "Berkeley Mono", weight = "Regular" },
	{ family = "NotoSansM Nerd Font" },
	{ family = "PragmataPro" },
	{ family = "DejaVu Sans" },
	{ family = "DejaVu Sans Mono" },
	{ family = "DejaVuSansM Nerd Font Mono" },
	{ family = "Symbols Nerd Font" },
	{ family = "Symbols Nerd Font Mono" },
})
config.font_size = 14

return config

Expected Behavior

Right vertical pane buffer is scrolled without affecting/scrolling other neovim pane/s to the left.

Logs

14:51:18.785 INFO wezterm_gui > Spawned your command via the existing GUI instance.
Use wezterm start --always-new-process if you do not want this behavior.
Result=SpawnResponse { tab_id: 4, pane_id: 4, window_id: 4, size: TerminalSize { rows: 24, cols: 80, pixel_width: 640, pixel_height: 384, dpi: 0 } }

Anything else?

bug.mp4
@b-jure b-jure added the bug Something isn't working label May 28, 2024
@lmcanavals
Copy link

I have the exact same issue, I noticed it only happens with config.term = 'wezterm'. I commented that line out so it picks the xterm-256color by default and the glitch goes away. The undercurl, dotted, dashed, and all other underline styles still work.

@b-jure
Copy link
Author

b-jure commented Jun 8, 2024

@lmcanavals Thanks a lot that fixed it. I will keep this issue open, before it was working even with the 'config.term' being set to 'wezterm'.

@tk-chaos
Copy link

tk-chaos commented Jun 8, 2024

I have the exact same issue, I noticed it only happens with config.term = 'wezterm'. I commented that line out so it picks the xterm-256color by default and the glitch goes away. The undercurl, dotted, dashed, and all other underline styles still work.

Arigato gojaimaszu!

Worked perfectly for me, will reference in another relevant ticket. Seems like a recent bug, was NOT the issue a month ago. Cheers! <3

@tjex
Copy link

tjex commented Jul 6, 2024

@b-jure out of interest were you / are you using the multiplexer? This is also an issue (yet to be fixed) over at #4102

@b-jure
Copy link
Author

b-jure commented Jul 6, 2024

@tjex I wasn't using at the time of opening the issue.

@Geerayef
Copy link

Hello everyone!

I was experiencing the same issue as @b-jure.
I'm using WezTerm 20240203-110809-5046fc22 on Arch Linux, Wayland with NVIDIA driver version 555.58.02.
I manually set my TERM environment variable to "wezterm", but using config.term = 'wezterm' should produce the same result since it also sets the TERM environment variable.

I fixed it by installing and updating WezTerm terminfo by following the documentation for term, namely I ran the script snippet that downloads and updates the terminfo for WezTerm:

tempfile=$(mktemp) \
  && curl -o $tempfile https://raw.githubusercontent.com/wez/wezterm/main/termwiz/data/wezterm.terminfo \
  && tic -x -o ~/.terminfo $tempfile \
  && rm $tempfile

Afterwards, in Neovim, having vertically split buffers and scrolling the right one does not scroll the left one. Also, the nvim-cmp suggestions have a little documentation popup that is scrollable which would also scroll the buffer opened in the background, and that's fixed now as well.

I hope this helps.

@b-jure
Copy link
Author

b-jure commented Jul 18, 2024

@Tibor5 and @lmcanavals provided the fix, since it is working I will close this issue for now.

@b-jure b-jure closed this as completed Jul 18, 2024
Copy link
Contributor

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 18, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

5 participants