-
-
Notifications
You must be signed in to change notification settings - Fork 824
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
Screen redraw on macOS when using (Neo)vim #4102
Comments
Please capture a terminal recording:
The file is an asciicast (compatible with https://asciinema.org/) and can also be replayed using The terminal recording allows me to replicate what is being sent to the terminal without requiring me to install the same applications as you and replicate your configuration for everything. |
@wez recording added |
I got to realize that this happens only when connected to a UNIX domain. It does not happen when |
Also happening to me. version nightly: mac os 13.5 (going to upgrade soon...) Also using yabai. But it happens with yabai disabled as well. |
Happens to me as well, both on UNIX and SSHMUX sessions.
|
Same issue
I'm also using the unix domain (like #4102 (comment)) config.unix_domains = { { name = 'unix' } }
config.default_gui_startup_args = { 'connect', 'unix' } |
It's currently broken on macos. See wez/wezterm#4102
Update. This is also effecting windows in general throughout various TUI apps of mine. Closed screens are simply left in place visually, and then drawn over once I start to move around / edit within the actual screen I'm supposed to be seeing. Disabling mux totally for the moment as well which has rendered my launcher unusable as well as
|
Did anyone find a workaround? I really prefer (and rely on) wezterm's mux feature over tmux, but I can't use neovim inside it, which makes it unusable :( |
Hello! When I go into insert mode and make modifications, nothing appears/updates on the screen until I hit Note that this issue does not happen immediately for me, but after a certain amount of time (I haven't timed it). I do not have this issue in iTerm2 with the same exact config otherwise. Here is my config: local config = {}
local wezterm = require("wezterm")
if wezterm.config_builder then
config = wezterm.config_builder()
end
-- Configure looks
config.color_scheme = "Sonokai (Gogh)"
config.font = wezterm.font("JetBrains Mono", { weight = "Regular" })
config.font_size = 16
-- Configure window opacity
config.window_background_opacity = 1
config.inactive_pane_hsb = {
saturation = 0.8,
brightness = 0.7,
}
-- Config for window
config.hide_tab_bar_if_only_one_tab = true
config.window_frame = {
font_size = 16,
}
config.window_decorations = "RESIZE"
config.window_padding = { left = 10, right = 10, top = 10, bottom = 0 }
-- Other settings
config.use_dead_keys = true
config.enable_scroll_bar = true
config.adjust_window_size_when_changing_font_size = false
return config |
As described in #5481, this bug reproduces with a simple sequence of |
I have recorded a brief example of the issue (I'll try to post a better one when I can, but as usual, these problems tend to occur when I'm not recording!). The issue is intermittent and challenging to diagnose, yet it happens quite frequently. In my situation, everything is up to date, and I have encountered this issue on both macOS and Arch Linux. This behavior occurs in both Neovim and the terminal itself. My recording is in Neovim, with an on-screen keylogger. If you play the video slowly, you can see that some actions are not displayed until another action is performed. Here are some specifics from the recording:
When this issue occurs in the terminal, I can type commands, but the letters do not appear until I hit enter a few times. Additionally, when a command produces output, the output does not appear unless I press a key on the keyboard. Thank you for your help and your amazing terminal! Screen.Recording.2024-06-14.at.15.22.45.mov |
Happens to me as well, but on ssh sessions and on a different OS.
Worked around by setting multiplexing to config.ssh_domains = {
-- rest of config here...
multiplexing = 'None',
} |
Same for:
|
I also had this affecting me for quite a while. I'm wondering if anyone has experienced this with a recent-ish nightly/main build. #4607 has discussion around a similar combination (mux + neovim drawing) that has been resolved. I'm working against the source-built version from #5576 to test floating panes, and thought I would turn mux back on to see if it happened to fix this, and so far I have not hit it. Only a few hours of driving, though, so it's possible I'll hit it again. If so I can report back here. |
Thanks @loops for their work on this. Tested on Mac 15 with SSH multiplexing and it works wonders. It seems this issue can finally be resolved. |
This reverts commit 6d4bc02.
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. |
What Operating System(s) are you seeing this problem on?
macOS
Which Wayland compositor or X11 Window manager(s) are you using?
yabai
WezTerm version
20230806-091840-2a7167a0
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
It seems that there is an issue with the redrawing of the screen whenever scrolling in neovim.
Wezterm.neovim.redraw.mov
To Reproduce
In a pane, open vim or neovim with a file that has at least half the number of lines shown on the screen
Split the windows horizontally with
:sp
In the upper window, go to the top line in the buffer and start scrolling down. Notice how the screen is redrawn in the bottom window.
Note: Hitting CTRL+L refreshes the full screen and the bottom window is redrawn as expected
wezterm-recording-REMpIT.cast.txt
Configuration
Expected Behavior
No response
Logs
No response
Anything else?
No response
The text was updated successfully, but these errors were encountered: