This is an unpopular opinion, but using vi over ssh - or any editor - has always struck me as a hack. You get high keystroke latency if the server is far away,

This is an unpopular opinion, but using vi over ssh - or any editor - has always struck me as a hack. You get high keystroke latency if the server is far away, which seems to bother me more than most people (in part because it’s unnecessary). You don’t have your settings and bindings by default, so you have to either get used to the default experience or copy your settings onto every server you use. Similarly, you get some random version of vim by default (not nvim), so if you want the latter, or any other editor, you have to install it. If the device you’re SSHing into is an embedded system like a router, that may be difficult or impossible or at least waste valuable disk space. And you’re stuck with a terminal, no GUI (even vim has some enhancements in GUI mode) - that is, unless you use X forwarding, but that’s an even bigger wasteful installation, given that most servers have no business having the X libraries installed. In theory, a saner approach is using a local editor to edit remote files. But people don’t do that. Why? Because the available implementations suck. NFS sucks because it’s slow and hangs your programs; sshfs is the same but worse. Vim has native remote file support in the form of scp://, which invokes the scp command every time you open or save a file - synchronously, so even if you’re saving you have to wait. This might be vaguely tolerable if you configure ssh to share connections, but in general it sucks. And with any of those, you have to set up a separate connection to the server and re-find the directory you’re in, which may or may not be time consuming. By contrast, typing vi into the SSH prompt usually just works, so that’s what people do. But there’s no fundamental technical limitation here. Imagine if you could type ‘edit foo.conf’ on the server and have it pop open a native editor on the client side. File transfer would be tunneled through the existing SSH connection, with no setup time or need for re-authentication; it would be fully asynchronous, so the editor would never hard-block waiting for an operation to complete, but it would still indicate when saves have been completed, so you know when it’s safe to run commands on the server that use the new files. Thing is, none of what I just said is especially complex or challenging from a technical perspective; it’s just that it would require changes to a bunch of components (ssh on the client and server; vim) that weren’t designed with that use case in mind. Anyway, I’m getting a little off topic here - but I think the point generalizes. In my ideal world, the future of X forwarding would be fixing the most common use cases so you don’t need X forwarding. For the rest, well, the ‘server sets up a tunnel over SSH’ approach could work just as well for VNC, or for an improved remote display protocol that uses a video codec. In the real world, I suppose things will just fester, remote display support will get worse, and remote editing will continue to suck. But I can dream. Or maybe implement something myself, but there are so many other things to do…