Neovim: [SOLVED] terminal starts dancing when opening a directory in neovim :)

[gaurav712]

• nvim --version: NVIM v0.3.4
• Vim (version: ) behaves differently? yeah , it does. Version is : VIM - Vi IMproved 8.1 (2018 May 18, compiled Mar 6 2019 21:38:32)
• Operating system/version: Arch Linux (up-to-date)
• Terminal name/version:tried it on latest st, termite and alacritty (it doesn't matter what terminal you are using)
• $TERM:st-256color(for st), xterm-termite(for termite) and xterm-256color(for alacritty)

Steps to reproduce using nvim -u NORC

It just behaves the same. No matter if I use config-file or not
I tried nvim .scripts/ to open the directory specified ☝️

Actual behaviour

It just goes crazy. Terminal window starts changing it's size like 20 times a second. I know I can't explain it better with words so, have a look at this : https://github.com/neovim/neovim/issues/9847. If you want the directory I was trying, it here (named '.scripts') : https://github.com/gaurav712/dotfiles_sway.

Expected behaviour

Well, you know how it should behave. Show the files. Don't do crap stuff.
The thing is, I like NEOVIM a lot and don't wanna keep vim installed just for some special task.

[KillTheMule]

There's no video in that repository. Please also provide specific steps for reproduction, how exactly do you open a directory?

[gaurav712]

Sorry, connection was slow then. It's there now. I didn't expect a reaction this quick.

[justinmk]

Thanks for the report. https://github.com/neovim/neovim/pull/9645 probably fixes this. Can you try the development version (0.4.0)?

The Releases page has pre-built archives for Linux/Windows/macOS. (No installation needed, just unzip and run. For Linux, nvim.appimage is a universal "binary", just chmod u+x nvim.appimage && ./nvim.appimage)

[gaurav712]

Still no effect. As you said, I tried https://github.com/neovim/neovim/releases/download/nightly/nvim.appimage and got the same results as before. Should I record another video?

[justinmk]

Never heard of this problem, so would need you to debug it. What happens if you remove tui_guess_size (and the calls to it)?

[gaurav712]

What I did :
//tui_guess_size(ui); (in function tui_terminal_start())
//tui_guess_size(ui); (in function sigwinch_cb())
And put the whole tui_guess_size() function in comments

And now it launches in a tiny part of the terminal. Something like 50*50pixels

[justinmk]

You say this happens when opening any directory? Or a specific directory with specific contents?

• Can you try commenting-out the four sections of tui_guess_size one-by-one, to see which section causes the issue?
• Can you try changing this line to:
  if (!got_winch) {

[gaurav712]

No effect!. Sorry for delayed replies. I cleared the compiled binaries. Had to compile again. God it's hell compiling something on a pentium.
And yeah, the previous one was when I was opening files/directories.

[justinmk]

Can you comment out these lines:

https://github.com/neovim/neovim/blob/3441423/src/nvim/tui/tui.c#L896-L898

If that doesn't work, I'm out of ideas. And "visit a directory" isn't enough for anyone to attempt to fix this.

[gaurav712]

That page says "Page not found"

[justinmk]

@gaurav712 fixed the link

[gaurav712]

Nothing! Tried all the possible combinations of those 3 expected solutions. I can live without "opening the directory" feature though.

[justinmk]

Try with TERM=ansi

[gaurav712]

again nothing

[justinmk]

Reopened since this seems to be affecting others. However if this change doesn't avoid the issue I don't know what to do. Can someone else confirm that change doesn't fix the issue?

And if that's confirmed, can someone bisect to the exact commit that caused this?

[puresick]

Reopened since this seems to be affecting others. However if this change doesn't avoid the issue I don't know what to do. Can someone else confirm that change doesn't fix the issue?

And if that's confirmed, can someone bisect to the exact commit that caused this?

I did a quick package downgrade on arch linux and the problem started with the 0.3.2 release. 0.3.1 with netrw v156 works fine!
I'll try to run down to the exact commit this is happening.

[puresick]

Reopened since this seems to be affecting others. However if this change doesn't avoid the issue I don't know what to do. Can someone else confirm that change doesn't fix the issue?

And if that's confirmed, can someone bisect to the exact commit that caused this?

BTW, uncommenting the 3 LOC in tui.c does not solve the problem, BUT I observed that the length of the flickering may depend on the count of files and folders in the current directory being opened.
I opened a dir with just one binary (the built nvim) and it just flickered a couple of times. After that it was usable until the dir changed!

I applied this "patch" to master.

[puresick]

@justinmk Ok I got the commit from which on this behaviour started: 05f9c7c.

[justinmk]

@justinmk Ok I got the commit from which on this behaviour started: 05f9c7c.

Interesting. @gaurav712 are you also using Wayland? As a workaround, trying forcing the clipboard provider to use something else, e.g. tmux:

    let g:clipboard = {
          \   'name': 'myClipboard',
          \   'copy': {
          \      '+': 'tmux load-buffer -',
          \      '*': 'tmux load-buffer -',
          \    },
          \   'paste': {
          \      '+': 'tmux save-buffer -',
          \      '*': 'tmux save-buffer -',
          \   },
          \   'cache_enabled': 1,
          \ }

Does that fix the behavior?

This seems like a bug in wayland/sway ( wl-copy or wl-paste provokes a resize?), but maybe we can add some logic that prevents hysteresis.

[puresick]

Interesting. @gaurav712 are you also using Wayland? As a workaround, trying forcing the clipboard provider to use something else, e.g. tmux:

    let g:clipboard = {
          \   'name': 'myClipboard',
          \   'copy': {
          \      '+': 'tmux load-buffer -',
          \      '*': 'tmux load-buffer -',
          \    },
          \   'paste': {
          \      '+': 'tmux save-buffer -',
          \      '*': 'tmux save-buffer -',
          \   },
          \   'cache_enabled': 1,
          \ }

Does that fix the behavior?

This seems like a bug in wayland/sway ( wl-copy or wl-paste provokes a resize?), but maybe we can add some logic that prevents hysteresis.

This fixed that behaviour for me!

[puresick]

Running wl-paste (wl-clipboard 1.0) manually in the terminal triggers some weird resize and returns to normal after it exits.

I'm not sure if this should be fixed here on neovims side. I think this might be a wl-paste (aka wl-clipboard) problem which needs to be adressed on their side.

EDIT: It seems that this issue is fixed in the current master of wl-clipboard.
Based on this comment I also tried the wl-clipboard-git package from Arch Linux AUR and it works without the clipboard config above!

[puresick]

Ok one more thing I noticed after using it for a few minutes with the updated wl-clipboard.
I still get weird glitches now (the cursor looks like it is redrawn really fast) and neovims cpu load rises to around 60% on one core (CPU: i7 7700HQ).

I now uninstalled wl-clipboard completely to prevent this.
Maybe there needs to be some workaround in neovim until wl-clipboard got this fixed.
I will open an issue on their side regarding this problem. => This could be a fix for the issue we're having: https://github.com/bugaevc/wl-clipboard/issues/31#issuecomment-462023847

[gaurav712]

Interesting. @gaurav712 are you also using Wayland?

Yeah, I am. Installing wl-clipboard-git from AUR as suggested by @puresick solved it for me but he's right about cpu load so I uninstalled it as well.

One more thing. As it's not a neovim issue, should it be marked as solved?

[justinmk]

One more thing. As it's not a neovim issue, should it be marked as solved?

Yes, but I think we could avoid the issue by some sort of "debouncing" logic.

[Hello71]

seems like neovim repeatedly executes and kills wl-copy --foreground --primary. this also has the side effect of leaving unlimited /tmp/wl-copy-buffer-* directories.

[justinmk]

seems like neovim repeatedly executes and kills wl-copy --foreground --primary.

@Hello71 what does :set clipboard? say? If you have clipboard=unnamed[plus] then yes, the clipboard backend will be invoked on every yank because that's what you told it to do.

his also has the side effect of leaving unlimited /tmp/wl-copy-buffer-* directories.

Are we invoking wl-copy incorrectly? Or what are you suggesting?

[Hello71]

not "on every yank", a zillion times on start. seems like a race condition too, attaching gdb and breaking on fork/clone makes it stop.

[justinmk]

@Hello71 isn't that the same behavior as already discussed above? https://github.com/neovim/neovim/issues/9806#issuecomment-480827573

[kovidgoyal]

Just FYI you can use OSC 52 (terminal escape code) to interact with the clipboard without needing to rely on any third party tools. The only downside with OSC 52 is that it may or may not be available in all terminals and may or may not be turned on by default. For instance, in kitty, writing to the clipboard is enabled by default but reading is turned off for security reasons, the user has to enable it in kitty.conf.

It might be worth adding a "terminal" provider to the list of clipboard providers you already have. Note that the version of the OSC 52 protocol that kitty implements is slightly modified (in a way that has no bad side-effect in other terminals) to allow for copying arbitrary lengths of text https://sw.kovidgoyal.net/kitty/protocol-extensions.html#pasting-to-clipboard

[justinmk]

@kovidgoyal thanks for the note. See also https://github.com/neovim/neovim/issues/3344

[NilsIrl]

@Hello71 isn't that the same behavior as already discussed above? #9806 (comment)

Yes, the artifacts are cause by wl-paste. However it seems that nvim is somehow calling wl-paste many times for unknown reasons.

So even when wl-paste won't produce this problem there will still be the problem that neovim calls wl-paste repeatedly.

[NilsIrl]

Are we invoking wl-copy incorrectly? Or what are you suggesting?

This seems to be the case

[justinmk]

Can you be more specific?

[NilsIrl]

Calling wl-paste causes the screen to flicker and artefacts appear (or whatever you want to call it, example can be found in #9847). This is caused by some strange stuff in wl-paste that resizes windows. This was fixed in wl-paste master so the problem isn't present anymore.

However, there is still the problem that vim calls wl-paste repeatedly. According to @puresick the CPU can have 60% usage. (I can't give personal data because once netrw is started and the flickering starts my only solution is to unplug my computer).

Quotes from others that sum up the problem:

Ok one more thing I noticed after using it for a few minutes with the updated wl-clipboard.
I still get weird glitches now (the cursor looks like it is redrawn really fast) and neovims cpu load rises to around 60% on one core (CPU: i7 7700HQ).

Yeah, I am. Installing wl-clipboard-git from AUR as suggested by @puresick solved it for me but he's right about cpu load so I uninstalled it as well.

@justinmk Ok I got the commit from which on this behaviour started: 05f9c7c.

[justinmk]

@NilsIrl that doesn't add any new information that wasn't already posted here. We have reports here that "aligning some wayland dependencies" solved the problem. So when you say "wl-copy is being invoked incorrectly", I need to know what's incorrect and how to correct it, rather than just guessing.

[NilsIrl]

So when you say "wl-copy is being invoked incorrectly"

Also it's wl-paste not wl-copy.

Correct is: don't call wl-paste repeatedly for unknown reason

Incorrect: call it repeatedly (more than once per second)

I don't know anything about vim internals but the problem could also be present on xclip. I don't see why vim would be calling wl-paste wrongly while calling xclip correctly.

[justinmk]

If you have clipboard=unnamed[plus], then again, please review the above. That setting tells Nvim to invoke the clipboard whenever the editor yanks anything. netrw also may invoke the clipboard many times.

"Invoking wl-{paste,copy} incorrectly" means "sending the wrong args". It does not mean "invoking the tool many times".

We could potentially try to "defer" clipboard invocation to workaround this issue, but that doesn't explain why "terminal dances around" (which is the issue you are posting in, and is wayland-specific).

Please only post new, relevant information, to keep the ticket from getting filled with noise.

Since you can reproduce the issue, perhaps you can debug it.

[Hello71]

summary of the status as of a few months ago: under some circumstances, including at least some invocations of netrw, neovim will repeatedly call wl-copy, wl-paste, or both (not sure which). under wl-clipboard 1.0, each invocation of wl-copy or wl-paste (not sure which) causes a zero-sized window to pop up for a brief moment (a few milliseconds). by default under sway, this causes the current pane to be divided in half for the duration that the window is open. with wl-clipboard git, the window no longer appears due to the completion of bugaevc/wl-clipboard#31. however, wl-copy is still repeatedly called, at least in some invocations of netrw. this causes some unnecessary CPU load, as well as creating many copies of /tmp/wl-copy-buffer-*.

[justinmk]

as well as creating many copies of /tmp/wl-copy-buffer-*.

Won't that happen even if it is less frequent?

[Hello71]

OK, since you insist, I did some more investigation. neovim repeatedly starts and then kills wl-copy with SIGTERM. this causes it to leave behind the wl-copy-buffer directory. I see two solutions: probably, wl-clipboard should support SIGINT or SIGTERM to cleanly remove the buffer directory and exit; also, neovim can stop passing -f and micromanaging the wl-copy instances and instead allow them to automatically terminate when another item is copied.

[justinmk]

Sounds good. The code is in provider/clipboard.vim , it's just vimscript.

[NilsIrl]

this causes it to leave behind the wl-copy-buffer directory

@Hello71 I cannot confirm what you are saying however, I am sure that wl-copy 1.0 produces a file in /tmp that is never removed regardless of if it is killed or whatever. This only happens when wl-copy uses stdin as the source of information. So the files in /tmp might not be related.

proof:

$ cd /tmp
$ ls -d wl-copy*
ls: cannot access 'wl-copy*': No such file or directory
$ wl-copy "please copy this"
$ wl-paste
please copy this
$ ls -d wl-copy*
ls: cannot access 'wl-copy*': No such file or directory
$ wl-copy
please copy this
$ ls -d wl-copy*
wl-copy-buffer-q1TGnc
$ wl-paste
please copy this

[djsavvy]

I was having the same problem, also referenced in #6695

I discovered the following workaround (to be put in nvim.init):

" Enable system clipboard integration
set clipboard+=unnamedplus
" Workaround for neovim wl-clipboard and netrw interaction hang 
" (see: https://github.com/neovim/neovim/issues/6695 and
" https://github.com/neovim/neovim/issues/9806) 
let g:clipboard = {
      \   'name': 'myClipboard',
      \   'copy': {
      \      '+': 'wl-copy',
      \      '*': 'wl-copy',
      \    },
      \   'paste': {
      \      '+': 'wl-paste -o',
      \      '*': 'wl-paste -o',
      \   },
      \   'cache_enabled': 0,
      \ }

Essentially, it works by overriding the calls to wl-copy and wl-paste to avoid using the -f foreground flag, which is what causes the tiny window to pop up.

[NilsIrl]

I was having the same problem, also referenced in #6695

What version of wl-clipboard do you have?

[djsavvy]

I am using the latest version of wl-clipboard in the Arch repositories:
2.0.0

Note that this is the same version provided by wl-clipboard-git in the
AUR.

(Edit: also, note that installing wl-clipboard-x11, as recommended elsewhere, did not solve the problem either)

[NilsIrl]

Also what version of neovim?

[djsavvy]

NVIM v0.4.3
Build type: Release
LuaJIT 2.0.5
Compilation: /usr/bin/cc -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -O2 -DNDEBUG -DMIN_LOG_LEVEL=3 -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wmissing-prototypes -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fdiagnostics-color=always -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -I/build/neovim/src/build/config -I/build/neovim/src/neovim-0.4.3/src -I/usr/include -I/build/neovim/src/build/src/nvim/auto -I/build/neovim/src/build/include
Compiled by builduser

[NilsIrl]

NVIM v0.4.3
wl-clipboard 2.0.0

This is very odd. Under this configuration I have no problems. I think switching to wl-clipboard 2.0.0 did fix the issue (though it didn't fix the underlying problem).

[the42]

I am still affected by the bug and the workaround described in https://github.com/neovim/neovim/issues/9806#issuecomment-586666047 does not work for me.

I am using wl-clipboard 2.0.0, wl-paste as in wl-clipboard 2.x has no flag -o
Besides that I am using the custom let g:clipboard from the mentioned proposed fix to prevent the --foreground flag of wl-copy (wl-paste has no --foreground - flag)

Opening netrw still causes heavy spawning of wl-clipboard processes which still opens a window. The Gnome App title flashes quickly to display the wl-clipboard app title until I have to kill nvim.

[djsavvy]

I'm on a WSL2 system now, so I can't check for sure, but I think my workaround stopped working for me as well. Not sure what changed.

[the42]

Any update on this? I am more than willing to provide further information, as I still have no workaround why constantly wl-clipboard process gets spawned when e.g. calling :Lexplore

Not using unnamedplus option

[the42]

Update: If I get rid of all vim-specific fixes, NetRw works. Still doing some quick "dance" but after maybe half a second it stabilizes. I am willing to accept that this is a Wayland-Gnome issue outside the reach of NeoVim and should be fixes upstream:

https://gitlab.gnome.org/GNOME/gtk/-/issues/2307

[gaurav712]

@the42 yeah of course the main problem is, all the projects neovim, wl-clipboard, and gnome aren't owned by any single authority. So its hard to make them all co-operate. For now I guess, all we can have are workarounds. Neovim itself works pretty well but it can't fix this issue solely.