Very slugghish experience in neovim when a colorscheme is set

[egolep]

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

Linux X11

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

qtile

WezTerm version

wezterm 20220907-075508-5cae889c

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

As soon as I define a colorscheme in neovim (no matter which one) everyting gets laggy and sluggish if I connect to the multiplexer. Without multiplexer everyting is fine

To Reproduce

Use the wezterm and neovim configs given below.

Then connect to the unix domain (both locally or via the ssh domain) and open something with neovim.

Configuration

Wezterm config:

local wezterm = require 'wezterm';

return {
    font = wezterm.font{
       family = "JuliaMono",
       weight = "Medium",
       --harfbuzz_features = { 'calt=1', 'clig=1', 'liga=1' },
    },
    font_size = 10,

    color_scheme = "tokyonight",

    hide_tab_bar_if_only_one_tab = true,

    keys = {
        { key="r", mods="CTRL", action="ReloadConfiguration"},
        { key="t", mods="CTRL", action=wezterm.action{ SpawnTab="DefaultDomain"} },
        { key="l", mods="CTRL", action=wezterm.action{ ActivateTabRelative=1} },
        { key="h", mods="CTRL", action=wezterm.action{ ActivateTabRelative=-1} },
        { key="j", mods="CTRL", action=wezterm.action{ ActivatePaneDirection="Next"} },
        { key="k", mods="CTRL", action=wezterm.action{ ActivatePaneDirection="Prev"} },
        { key="j", mods="ALT", action=wezterm.action{ SplitVertical={domain="CurrentPaneDomain"}} },
        { key="l", mods="ALT", action=wezterm.action{ SplitHorizontal={domain="CurrentPaneDomain"}} },
    },
    ssh_domains = {
        {
          -- This name identifies the domain
          name = 'daidalos',
          -- The hostname or address to connect to. Will be used to match settings
          -- from your ssh config file
          remote_address = 'daidalos',
          -- The username to use on the remote host
          username = 'fabio',
        },
    },
    unix_domains = {
        {
            name = 'unix',
        },
    },
    --default_gui_startup_args = { 'connect', 'unix' },
}

neovim config (watchout, is a little bit messy): https://pastebin.com/3gXG6EgA

Expected Behavior

Neovim editing should be smooth like everything else in wezterm

Logs

No response

Anything else?

No response

[wez]

Please capture a terminal recording of nvim running in wezterm but without the multiplexer. The recording will allow me to replay it inside a multiplexer.

• Launch wezterm. If possible, please use the default terminal size of 80x24 cells as it helps to keep things smaller and easier to manage.
• Inside that terminal run wezterm record to start a recording session.
• Run through your reproduction steps
• Then type exit
• You should see a message like:

*** Finished recording to /var/tmp/wezterm-recording-sF6B3u.cast.txt

• Attach the file that it produced to this issue.

The file is an asciicast (compatible with https://asciinema.org/) and can also be replayed using wezterm replay.

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.

[egolep]

Suddenly, something is changed: when I start wezterm via the unix socket, even though my wm draws a full window, wezterm actually uses a very small part of it: https://imgur.com/a/L6pZ9Jf

When only the small part is used, everything is snappy. If I redraw the window (i.e. toggle fullscreen on and off via the wm) it starts using the whole window and becomes sluggish.

Should I still do the recording procedure or this is more revealing?

PS: thanks for your very quick reply!

[wez]

That sounds like https://github.com/wez/wezterm/issues/2351 Please do share the recording!

[egolep]

Here the recording text (on a pad because it's pretty big): https://pad.gattini.ninja/p/wezterm-record

However, I've been unable to resize the window when in "recording state", so everything was smooth. By "unable" I mean that, after the aforementioned double toggle of fullscreen, I was still locked with a small part of the window used like in the images posted above.

[wez]

The link doesn't work for me. Please just zip up the .txt file and attach it to this issue

[wez]

if the issue only reproduces at a certain screen size, then record at that size. The important thing is to not resize while recording.

[egolep]

wezterm-recording-LcJjFV.cast.txt Hope this works now. I resized before recording and I noticed it a little bit less slow.

[mfiano]

I can confirm, and this is very sluggish indeed. I might have to put wezterm on hold as I spend most of my time in vim.

Note: Performance increases slightly if you omit a font or font_with_fallback wezterm setting from your config, but still enough to be painfully slow.

And indeed, no multiplexing is fast.

[kaddkaka]

However, I've been unable to resize the window when in "recording state", so everything was smooth. By "unable" I mean that, after the aforementioned double toggle of fullscreen, I was still locked with a small part of the window used like in the images posted above.

You might be able to trigger the same slowness by just downsizing the font a lot. Might be worth a try.

[supernomad]

So for what its worth, I am also seeing this behavior when using multiplexing + neovim/vim from a windows laptop to a linux server using version:

❯ wezterm --version
wezterm 20221119-145034-49b9839f

And indeed when I manually ssh to the server from within a local wezterm instance on my windows laptop and run neovim everything is snappy and works as expected.

[lsjostro]

Experience the exact same thing. neovim lags from time to time in a mux session. Running ssh directly from wezterm without server muxing works without any problems. Did a recording if that helps @wez. wezterm-recording-QVnyin.cast.txt.gz

[lsjostro]

removing prediction "solves" the problem for me. Something with unix_domain + prediction which makes things super laggy. https://github.com/lsjostro/dotfiles/commit/66cd01d8e82e7347c51d19f75ab3d19d721cfe94

I have a 4-6ms latency to my remote mux server which also might help in my favor.

[cd-a]

Have the same issue on macOS 13.2.1.

Was very excited about the local unix socket, but scrolling in neovim is so slow that even after releasing the key, it still scrolls on for 2 seconds. Without the mux it's blazing fast, much more so than kitty.

It's a very basic wezterm config, just enabled the mux and set the theme and font size.

Please let me know what I can do to help, screen recordings etc.

[wez]

Duplicate of https://github.com/wez/wezterm/issues/1872

[github-actions[bot]]

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.