[vim/vim] "gvim --remote-tab-silent" seems to be broken under version 9.1.1623 (Issue #17982)
thunderbird-1990
thunderbird-1990 created an issue (vim/vim#17982)Steps to reproduce
touch 1.txt 2.txt
gvim --remote-tab-silent 1.txt
gvim --remote-tab-silent 2.txt
Expected behaviour
I expected both files to be opened under the same instance of gVim as separate tabs. They are instead opened in separate gVim instances/windows.
This is not a problem under version 9.1.1552 (I downgraded both gvim and vim-runtime to 9.1.1552, and the issue does not exist).
Also this might be related to #17747:
gvim -g --servername TEST
gvim -g --serverlist
returns nothing under version 9.1.1623, but TEST under version 9.1.1552.
Version of Vim
9.1.1623
Environment
Arch Linux, KDE Plasma 6.4.4, KWin (Wayland)
Logs and stack traces
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Foxe Chen
64-bitman left a comment (vim/vim#17982)@thunderbird-1990 Any follow up?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
thunderbird-1990
thunderbird-1990 left a comment (vim/vim#17982)I can confirm this is not a problem with gVim 9.1.1623, Arch Linux, and XFCE (X11).
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#17982)so this is still happening?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
thunderbird-1990
thunderbird-1990 left a comment (vim/vim#17982)As of today, yes, this is still happening with gVim 9.1.1623, Arch, and KDE (Wayland). But not with XFCE (X11).
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Petr Menšík
pemensik left a comment (vim/vim#17982)Hi! It happens to me also, I have VIM - Vi IMproved 9.2 (2026 Feb 14, compiled Mar 06 2026 00:00:00) on Fedora, with +wayland and +clientserver enabled.
I created alias alias gvimt='gvim --servername "GVIM-$(pwd)" --remote-tab-silent' to open files from the same project. It used to work, but stopped after upgrade to Fedora 43.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
dezza
dezza left a comment (vim/vim#17982)Can any of you guys try to debug print to see where it goes wrong; check #17839
Insert for example
fprintf(stdout, "reached %d", "1"); fflush()
The wayland clientserver is relatively new, maybe you can read fron the source where it could be problematic.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Petr Menšík
pemensik left a comment (vim/vim#17982)I have never compiled vim myself, use normal package. I will ask @zdohnal to reproduce it with sources. This one should be relatively simple to reproduce. I am using gvim, which I think used some X based interface instead.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#17982)have you tried the socketserver then?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Petr Menšík
pemensik left a comment (vim/vim#17982)yes, socket client server seems to be working as expected. Except it does not accept working directory path the same way as x11 did. Can I use working directory as part of --servername with --clientserver socket? How do I do that?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Petr Menšík
pemensik left a comment (vim/vim#17982)Hmm, servername with socket backend deletes unconditionally the given path. I am lucky it could not delete my --servername "$PWD", because the directory is used in that case. Perhaps it should use stat() to check existing types and refuse to start, when path is directory or normal file? I think user does not want to get it deleted, if he gives path to existing file by mistake.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Petr Menšík
pemensik left a comment (vim/vim#17982)I would have expected there would be compatible naming possibility for new and old methods. But have not found how to include working directory name into servername. Tried this:
# does not open new server, terminates without opening gvim gvim -f --servername "$(pwd)/.vim-server.sock" --clientserver socket --remote-tab-silent file1 # does open new server and gvim editor gvim -f --servername "$(pwd)/.vim-server.sock" --clientserver x11 --remote-tab-silent file1
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Foxe Chen
64-bitman left a comment (vim/vim#17982)I would have expected there would be compatible naming possibility for new and old methods. But have not found how to include working directory name into servername. Tried this:
# does not open new server, terminates without opening gvim gvim -f --servername "$(pwd)/.vim-server.sock" --clientserver socket --remote-tab-silent file1 # does open new server and gvim editor gvim -f --servername "$(pwd)/.vim-server.sock" --clientserver x11 --remote-tab-silent file1
Problem is that the socketserver cannot have slashes in it unless it starts with "./", "../", or "/". Maybe you can replace the slashes with "%" characters?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Petr Menšík
pemensik left a comment (vim/vim#17982)$(pwd) starts with "/" on any system I know. It uses unix socket with path specified. It should be safe, right? Of course I can transliterate password to not contain slashes, but I wanted the actual socket to reside in my working directory.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Foxe Chen
64-bitman left a comment (vim/vim#17982)
$(pwd)starts with "/" on any system I know. It uses unix socket with path specified. It should be safe, right? Of course I can transliterate password to not contain slashes, but I wanted the actual socket to reside in my working directory.
Does this patch fix your issue?
diff --git a/src/clientserver.c b/src/clientserver.c index ae5130dd3..b5f8d678b 100644 --- a/src/clientserver.c +++ b/src/clientserver.c @@ -300,6 +300,15 @@ prepare_server(mparm_T *parmp) # endif vim_free(parmp->servername); } +#ifdef FEAT_SOCKETSERVER + // We don't need to delay starting the socket server, so start it + // immediately. + else if (clientserver_method == CLIENTSERVER_METHOD_SOCKET) + { + if (socket_server_init(parmp->servername) == OK) + TIME_MSG("initialize socket server"); + } +#endif # ifdef FEAT_X11 else serverDelayedStartName = parmp->servername; diff --git a/src/os_unix.c b/src/os_unix.c index 3bd2942ca..2756e2f52 100644 --- a/src/os_unix.c +++ b/src/os_unix.c @@ -9113,6 +9113,8 @@ socket_server_init(char_u *name) int num_printed; int fd; int i = 1; + bool explicit = false; + bool success = false; if (socket_server_valid() || (name == NULL && socket_server_path == NULL)) return FAIL; @@ -9138,8 +9140,11 @@ socket_server_init(char_u *name) // socket. if (name[0] == '/' || STRNCMP(name, "./", 2) == 0 || STRNCMP(name, "../", 3) == 0) + { num_printed = vim_snprintf((char *)path, sizeof(addr.sun_path), "%s", name); + explicit = true; + } else { const char_u *dir; @@ -9207,11 +9212,11 @@ socket_server_init(char_u *name) vim_snprintf(addr.sun_path, sizeof(addr.sun_path), "%s", path); - // Bind to a suitable path/address - while (i < 1000) + // Bind to a suitable path/address, do not loop if path is explicitly + // provided. + do { - if (bind(fd, (struct sockaddr *)&addr, sizeof(addr)) - == -1) + if (bind(fd, (struct sockaddr *)&addr, sizeof(addr)) == -1) { int fd2; @@ -9227,13 +9232,17 @@ socket_server_init(char_u *name) if (fd2 == -1) { mch_remove(addr.sun_path); + i++; continue; } else close(fd2); } else + { + success = true; break; + } num_printed = vim_snprintf(addr.sun_path, sizeof(addr.sun_path), "%s%d", path, i); @@ -9246,9 +9255,9 @@ socket_server_init(char_u *name) } i++; - } + } while (!explicit && i < 1000); - if (i >= 1000) + if (!success) { emsg(_(e_socket_server_unavailable)); goto fail;
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Foxe Chen
64-bitman left a comment (vim/vim#17982)It also seems that if the GTK gui is running under Wayland, then the X11 clientserver backend does not work. Just want to point that out
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Foxe Chen
64-bitman left a comment (vim/vim#17982)cc @pemensik
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Petr Menšík
pemensik left a comment (vim/vim#17982)
$(pwd)starts with "/" on any system I know. It uses unix socket with path specified. It should be safe, right? Of course I can transliterate password to not contain slashes, but I wanted the actual socket to reside in my working directory.Does this patch fix your issue?
Yes, it stops endless loop when directory is used as a server path. I think it should print some error message also, but it does not print anything.
Used for testing:
#!/bin/sh # https://github.com/vim/vim/issues/17982 : ${SERVER:=socket} : ${SERVERNAME:="$(pwd|tr / %)"} : ${VIM:=gvim} echo file1 > /tmp/file1 echo file2 > /tmp/file2 $VIM -f --servername "$SERVERNAME" --clientserver $SERVER --clean --remote-tab-silent /tmp/file1 & PID1=$! sleep 1 $VIM -f --servername "$SERVERNAME" --clientserver $SERVER --clean --remote-tab-silent /tmp/file2 & PID2=$! sleep 5 kill $PID1 $PID2
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Petr Menšík
pemensik left a comment (vim/vim#17982)but absolute or relative path to unix socket does not seem to work. "$(pwd|tr / %)/.vim.sock" works, but "$(pwd)/.vim.sock" does not. Nor does ./.vim.sock.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Foxe Chen
64-bitman left a comment (vim/vim#17982)It looks like the problem is that the socket server needs to become a server itself, so it creates one, but then connects to itself, then Vim exits thinking there was a server. I think this would require refactoring the existing code a bit, I will create a PR for this (might take a while).
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.