How do *you* use 'x11-clientserver'?

[dvogel]

Vim's clientserver feature is very platform-specific. On unix-like operating systems this depends on X11 functionality.

2. X11 specific items					*x11-clientserver*
				    *E247* *E248* *E251* *E258* *E277*

The communication between client and server goes through the X server.  The
display of the Vim server must be specified.  The usual protection of the X
server is used, you must be able to open a window on the X server for the
communication to work.  It is possible to communicate between different
systems.

The linux platform is going through significant changes regarding X11, with many distributions phasing X11 out completely. As that happens, vim's clientserver support will no longer work. So I'd like to get a discussion going regarding how people are using this feature today with an eye toward ways to keep this functionality working via alternative mechanisms going forward. One semi-obvious replacement candidate would be d-bus as that is the backbone of most modern linux desktops. However it occurs to me this might not be true under Microsoft's WSL or other "unix-like" setups where people might use vim.

So how do you use the x11-clientserver functionality today?

[georgalis]

This is my first vim related posting since the passing of Mr Moolenaar;
so, first I offer my deepest regards for his family, and prayers that the greatest
spirit in open source programming and author of the greatest editor, rest in peace.

~~ ~~ ~~

I didn't even know vim supported x11-clientserver. I used to love X11 forwarding over SSH for performance and access control, but it's just not practical anymore. There was a period I would run firefox in the server room because it would outperform the office workstation at my desk! The network demands are too high for X11 now. Today, that would saturate the fastest of network switches. Vim might be okay, but generally X11 support has been declining for years.

To the dismay of many peers, the very effective solution is RDP. Don't get me wrong, I've been a long time pundit of M$ tools, but in this case, a fair evaluation makes RDP the winner.

• All your users (Linux, Mac, BSD, and Windows) have a straight forward means to install their client.
• Probably there is a Mac server, in any event a server is straight forward to install on the other platforms.
• If there has ever been an RDP vulnerability, they certainly have not been frequent, and I've never heard of one.
• If you are worried about the network protocol from client to server, you can always use RDP over SSH.

For the server, typically all the bin packages are available from your OS vendor. You'll need a user account with a properly configured window manager, a display manager, a gui login manager, and the rdp server. The hardest part is getting all of these things working together, log files are golden, when you get crashing loops. You don't actually need an X11 server for this setup, so you'll save some resources there.

That's about it. Once all these tools are chained together, you'll forget how you got it going, but it will run forever.

-George

[georgalis]

To the dismay of many peers, the very effective solution is RDP. Don't get me wrong, I've been a long time pundit of M$ tools, but in this case, a fair evaluation makes RDP the winner.

After posting, I double checked my vocabulary and pundit does not have the meaning I thought, prejudice against would have been a better choice of words.

Anyway, for anyone wanting to try RDP protocol with OSS, I found my setup notes and I can confirm an old CentOS 7 VM with no GUI setup, does indeed still accept connections from my Mac with RDP client. Here are details for a setup example:

• install CentOS-7-x86_64-NetInstall-2009.iso
• yum install epel-release
• yum update
• shutdown -r now
• yum groupinstall Xfce
• yum install xrdp xterm
• echo "/usr/bin/xfce4-session" >>~/.xsession
• chmod +x ~/.xsession
• systemctl start xrdp.service
• systemctl enable xrdp.service
• firewall-cmd --permanent --add-port=3389/tcp
• firewall-cmd --reload

of course the firewall commands aren't necessary if you are connecting via ssh, in which case you would connect with something like this in your ssh config first LocalForward 2048 192.168.0.15:3389 and PC name 127.0.0.1:2048 in your RDP client. I think that's it!

-George

[AndrewRadev]

If you're asking about use cases, I use it to run tests for my plugins in Ruby with Vimrunner. I spawn a vim --servername <something-random>, then loop over vim --serverlist with a sleep until the name is active and send messages to the server to drive it through scenarios. In remote builds, I use xvfb-run, for example in splitjoin

I also sometimes send build output to a Vim instance. I've described the process in a blog post, but the short of it is setting --enable-autoservername in the compilation flags and then after a build, putting the output in to a file, finding the right Vim via its working directory and then using cfile to load the quickfix.

[k-takata]

The bundled editexisting plugin uses it.
(I use it on Windows, though.)

[laburnumT]

I use it when editing latex to get reverse search from the pdf to my latex source.