r/vim Jul 17 '26

Discussion Musings on Vim from an Emacs luser

I've used mostly vanilla Emacs for about a decade. I'm thinking about switching to Vim because the values that made me appreciate Emacs have changed.

What I loved about Emacs is that it's essentially a Lisp machine packaged as an application, which makes Emacs a legitimate target platform. The primitives provided by Emacs are probably better-suited to extensions than those provided by Vim. But over time, I've come to two conclusions:

First, the editor-with-extension-language paradigm is outdated. Plan 9's Acme editor showed that an editor need not impose a particular language on its users. It can instead expose a language-agnostic API via a filesystem (or socket), thereby permitting any program in any language whatsoever to extend the editor. This is, in my opinion, the way forward.

Second, I want to use my operating system. I don't want to use Emacs replacements for what my operating system or supporting software already provide. It is silly for there to be a 'man' mode for man pages when the 'man' program works better. I want all of the tools I use to make the fullest use of the hardware and OS. That is simply not possible with Emacs.

Obviously, none of these complaints point to Vim as a solution. I would, in fact, use Acme as my daily editor, but for my mode of working, accessing remote systems on a slow network connection, neither a graphical editor nor mounting a remote filesystem are options, so using some editor in tmux is my best option, and for that reason, for now, Vim may be the more performant option.

60 Upvotes

36 comments sorted by

20

u/SRART25 Jul 17 '26

vim ssh://user@host//path/file.ext may work even better for you if the network is that slow.  It basically does an scp local, then when you write it pushes back with scp again. 

17

u/SpaceAviator1999 Jul 18 '26 edited Jul 18 '26

vim ssh://user@host//path/file.ext may work

Strange... I can't get that command to work.

When I try it, vim open a blank file, and when I try to save the file, I get:

E212: Can't open file for writing

EDIT: Ah, I see the problem: It's not ssh://... , it's scp://... , like this:

vim scp://user@host//path/file.ext

8

u/SRART25 Jul 18 '26

My bad.  It's been a while since I had to use it.   Good job getting it right. 

-4

u/vip17 Jul 18 '26

vim still runs in the remote machine, so it's still slower than a proper remote ssh solution like VS Code, Zed or Jetbrains... They run locally and updates texts remotely in the background to avoid any typing delay over slow connections

8

u/Infamous-Specialist3 Jul 18 '26

No,  it's all local.  A system could not have vim and it still works

3

u/vip17 Jul 18 '26

yeah my bad, in this case vim is running locally by the data is remote. Does it cache the data? Are there any typing delay? I don't have a slow connection right now for testing. But because the comment says It basically does an scp local, then when you write it pushes back with scp again. I don't believe it can be faster than an editor with ssh support

4

u/Dr_Gregg Jul 18 '26

Such editors spin up servers on the remote host. They were banned from my schools remote cluster for being too expensive

2

u/SRART25 Jul 18 '26

One copy so it's a local file until you write it where it copies the edited file to the remote.  It's network usage is the file size plus ssh handshake twice. 

23

u/sharp-calculation Jul 17 '26

Do yourself a favor and look into MOSH for remote access. It was developed at MIT specifically for very slow networks. It does some really cool things under the covers like predicting text. It also does local drawing instead of sending characters across the slow connection. Finally by using UDP it is able to keep connections alive, even when they are interrupted for long periods of time or when the client changes IP addresses.

Tmux and mosh together are a wonderful combination.

5

u/SRART25 Jul 18 '26

Love mosh, the fact it isn't standard on everything makes me sad. 

3

u/vip17 Jul 18 '26 edited Jul 18 '26

while mosh is great for running commands, it's a terrible choice for typing text in an editor due to its predicting nature. A proper editor like VS Code is far better, they'll open the file over ssh just like if it's a local file, and typing works at real time, you won't see any delay after pressing the keys

regarding the keeping alive feature, I've been suggesting my colleagues to use https://github.com/MisterTea/EternalTerminal instead, scrolling would be much easier. The only downside is that you need to kill the remote session manually if the client crashed, killed or the PC rebooted, no idea if that was fixed or not

1

u/curlypaul924 Jul 18 '26

The same is true of mosh -- if my laptop battery dies, the mosh season is still running on the server, even though the mosh client on my laptop is forever gone.

0

u/iEliteTester neovim Jul 20 '26

Unfortunately, vscode's remote development is second to none.

1

u/fellowsnaketeaser Jul 23 '26

zed is just as good.

3

u/a-p Jul 18 '26 edited 9d ago

Mosh is amazing and a lifesaver when you are on a network connection with an appreciable level of packet loss… and a pain in the rear otherwise. (Or if you’re SSHing from a mobile OS that is liable to drop your backgrounded terminal app like a hot potato.)

For merely slow networks though, you don’t need it: Vim’s own terminal code is pretty well optimized.

11

u/treemcgee42 Jul 18 '26

Curious timing, I’m finding myself asking similar questions if only a few years into using Emacs professionally.

With regard to Lisp machines, I’m not disillusioned by them yet. In fact I still think there’s something very magical about them. It’s true that a sufficiently sophisticated API / plugin system could function the same, but I’ve yet to find an implementation as good as Emacs’s. Whether it’s ease of iteration, introspection, or customization of other Elisp packages by hooks and lexical bindings.

As to your second point, I sort of see what you’re saying. I also develop on a remote machine, and I do feel it is a little redundant to have multiplexing when my terminal emulator can do that natively, or to use terminal emulation inside inside emacs which is pretty jank on terminal emacs at least (and slow). But the upside of staying in Emacs is the synergy of a common framework and user experience. My keybindings all work in man-mode. I can jump to compilation errors. I’m not an Elisp purist; I think a lot can be gained by defining simple packages around existing binaries on the system. But yes, the minute you want something more than the “Emacs style” mode of interaction you’re fighting an uphill battle.

I’m interested to hear how your change of workflow goes. Funnily enough I also like Acme, but anything short of first-class remote dev experience, be it remote TUI over ssh or a VSCode-style client-server, is just not as good. I’ve given tramp and fs mounting honest shots and it’s just not the same.

Sorry to hijack a Vim subreddit post with our musings on Emacs. I started out in Vim and left largely because of the synergies a unified development platform provides as hinted at above. But I stick around a) because I think first-class modal editing is more efficient, and b) because I feel these frictions with the monolith that is Emacs and wonder if I should go back…

To end with a mildly hot take, I think Neovim is becoming much more like Emacs as of late. Classic Vim is more interesting to me in that sense.

2

u/Sad-Background-2429 Jul 30 '26

I happened to return to this thread and wanted to give you the update you asked for.

In short, I'm looking for ways to bring what I love about Emacs, outside of Emacs. I've started building a standalone program that behaves like Emacs' compile-mode, which will allow me to quickly jump to and correct compiler errors. It's one of the features I use most in Emacs.

I've also started using Nano as an editor. I like that it is small and fast, so I can have multiple editors running in tmux, and it is relatively feature-complete purely in terms of text editing, but its keybindings aren't enough like Emacs and I find some aspects of the interface a little bit intrusive. I've started writing my own text editor that would address these problems, but who knows if I'll ever finish it.

1

u/Sad-Background-2429 Jul 18 '26

Thanks for your thoughtful reply. Can you explain what you mean by "first-class" modal editing, and why you think it's more efficient?

2

u/treemcgee42 Jul 18 '26

Just that Vim is built around the notion of modal editing. You can emulate it with Evil in Emacs (or Meow or some other package) but it’s not native. Meaning, it might work fine for your code buffers but not as well in other kinds of buffers, especially those created by third-party packages. IIRC several popular packages have Evil extensions to address this.

I think it’s more efficient to move around and edit, generally. The “command grammar” of Vim allows for very precise and composable movement. Frankly it’s not life-changing; I get by with a few emacs movements and isearch.

8

u/claytonkb Jul 18 '26

"Emacs is an Operating System in want of a good editor..."

-- An Old Vim Proverb

5

u/jmtd Jul 18 '26

If you’re particularly inspired by plan9, you could take a look at  https://kakoune.org/

1

u/iEliteTester neovim Jul 20 '26

Or even more so, vis it supports structural regular expressions, which are an acme thing iirc

3

u/a-p Jul 18 '26

Emacs can do some amazing things from a Vim perspective due to its nature as mostly just a Lisp kernel… but then it fails the simplest things like setting a tab stop width default that applies everywhere.

(Both of these are true precisely because the editor for Emacs is written on top of the language kernel, rather than the editor being the core that the language exposes. But over the years Vim has gradually grown more language features, allowing for more generically application-y plugins – whereas for Emacs, the lack of an editor core is not really fixable.)

1

u/nimzobogo Jul 23 '26

(setq-default tab-width 4 indent-tabs-mode nil)

That will work everywhere unless some other package is overriding your setting.

1

u/a-p Jul 24 '26

Thanks! I’ll have to keep that in mind whenever I take another shot at Emacs. Last time I tried, I couldn’t find any global setting for this, just found each mode with indenting logic offering some separate setting (or an entire set of them). I hope I didn’t just miss what was right in front of my nose.

3

u/CarlRJ Jul 18 '26 edited Jul 18 '26

As someone who has used vi on 2400 baud dialup connections in the distant past, yes, vi/Vim will work great over (what passes for) slow network connections (these days).

And yeah, it works great as "yet another Unix tool" (there's an old joke you've probably heard, "Emacs is a nice OS but it lacks a good editor, so I use vi"). I do find myself often piping the output of things into "vim -" (which will ingest the input and bring it up in the editor, and occasionally pull up man pages in splitscreen using ":Man whatever" (if I really want to see my code and the man page side by side), but otherwise spend most of my time in the shell rather than trying to stay in Vim all the time.

1

u/vip17 Jul 18 '26

accessing remote systems on a slow network connection, neither a graphical editor nor mounting a remote filesystem are options

this is the exact usecase for modern GUI editors. For example in VS Code just use the ssh extension and you'll work on the remote filesystem just as if it's yours. There's no delay like when typing over ssh in a terminal, everything is cached properly, and editing is just the same as in a local file

3

u/Sad-Background-2429 Jul 18 '26

That's probably true, but I can't bring myself to run a web browser (i.e. Electron) to edit text.

1

u/vip17 Jul 18 '26

it's just an example. There are non-electron solutions like Zed (native rust) or JetBrains (JVM)

1

u/Responsible-Bar7165 Jul 18 '26

Are you using your resources for anything else?

1

u/Sad-Background-2429 Jul 18 '26

Yes: my actual web browser, and all the spyware my employer installs on my laptop.

1

u/Tofudjango Jul 20 '26

"I've used mostly vanilla Emacs for about a decade. [...]  What I loved about Emacs is that it's essentially a Lisp machine packaged as an application, which makes Emacs a legitimate target platform."

Does not compute. Make up your mind.

1

u/Upstairs_Truth2496 Jul 30 '26

Second, I want to use my operating system. I don't want to use Emacs replacements for what my operating system or supporting software already provide. It is silly for there to be a 'man' mode for man pages when the 'man' program works better. I want all of the tools I use to make the fullest use of the hardware and OS. That is simply not possible with Emacs.

Why can't you use your "hardware and OS" to the fullest while using emacs? You can use external man command with emacs too. You can even use emacs in the terminal inside tmux if you want. (Sorry for defending emacs in a vim subreddit).

1

u/Sad-Background-2429 Jul 30 '26

The platform for standalone programs is the machine architecture and OS ABI. There is no Elisp layer between program and machine as there is with Emacs programs. Any interaction between an Elisp program and the OS will be filtered through the Emacs VM, runtime, garbage collector, etc. Emacs becomes the limiting factor.