4 ms·
I used vi and vim for about 25 years before switching to Emacs. I did this because: 1 - I got deeply interested in Lisp and Scheme, and Emacs was reputed to h
by pmoriarty 7y ago
I used vi and vim for about 25 years before switching to Emacs.
I did this because:
1 - I got deeply interested in Lisp and Scheme, and Emacs was reputed to have the best editing environment for these languages
2 - Almost all of Emacs itself and Emacs' entire package ecosystem is written in eLisp, which is a tremendous improvement over vimscript, in which almost all vim packages are written. I'd just rather read and write eLisp over vimscript any day.[1]
3 - Emacs offers so much more than vim (or neovim). You read and write your email in Emacs, surf the web in Emacs, chat on IRC in Emacs, have deep shell integration in Emacs[2], read RSS news in Emacs, use org-mode (which vim only has pale imitations of) and do just about everything else you'd ever want in it, which is not really the goal of vim, and certainly the opposite of the minimalism of vi.
4 - Emacs had packages that would emulate vim (evil-mode being by far the best and most complete of them all), which would allow me to bring my decades of vim knowledge and plugins over to Emacs, so I'd feel right at home.
The switch was a success, and I've been using Emacs for about 10 years now. I have no reason to go back, as Emacs does virtually everything vim does and much more than vim doesn't.
There are still a few things I miss from vim, and I still fire it up on systems where Emacs is not installed and where I don't have my Emacs config (I don't like using Emacs' TRAMP mode, for reasons I won't go in to here), and for a few tasks where Emacs just isn't adequate.
For instance for editing files with really long lines or gigantic files which Emacs just chokes on.[3] vim's regex engine also has some features Emacs lacks (ie. vim's \zs and \ze zero-width patterns are ones I sorely miss in Emacs).
Otherwise, though, evil is a pretty feature-complete emulation of vim, and I don't find myself missing the latter much.
It did take me a really, really long time to get my Emacs configured to be the way I liked it, though.. and that's a never-ending process.
So I wouldn't necessarily recommend that other vim veterans switch to Emacs unless they've got a huge amount of time on their hands, love tinkering with their configs, and either already love or are open to learning to love Lisp. I happen to be one of those people, so it's worked well for me.
[1] - Yes, it's possible to write vim packages in Guile Scheme, but virtually no one does this. A Guile Scheme ecosystem doesn't exist for vim, so if I chose to write Guilde Scheme packages for vim, I'd pretty much be the only one doing it. Not so in Emacs, where everyone writes packages in eLisp.
[2] - Emacs' shell integration didn't turn out as great as I expected, as it's vulnerable to Emacs' atrocious handling of long lines, slowness, and buggyness of its shell modes (though libvterm is supposed to offer a real shell inside Emacs, which is reputed to be a lot better than other shell modes written in eLisp, but I haven't tried it).
[3] - vim also isn't great at files with super long lines and gigantic files, but it's better than Emacs.
- DonHopkins 7y agoAlso: Emacs has shell windows, process management, and output filtering, and keyboard macros, so it can run and control and respond to sub-processes (kind of like "expect" on steroids). I could not give up running shells in an emacs shell window, capturing all the output as normal text I can edit and search with the full power of emacs, instead of a dumb scrolling terminal emulator, and the ability to make keyboard macros that hop between text files and dired directory listings and shell windows, copying file names and data to fire off sequences of shell commands. Easy on-the-fly automation of repetitive tasks. Why write a single use shell script when you can just do it once by hand while recording a keyboard macro, then repeat it thousands of times.
- pmoriarty 7y agoSo what do you do when some shell command you run chooses to spit out a bunch of really long lines? Emacs would freeze on me when this happens. Is there a way around this apart from running a shell under libvterm? Or is this even still an issue under libvterm too?
- alexhutcheson 7y agoNot OP, but that hasn't come up for me very often. If a command output is really long or takes a long time to run I'll normally run it using M-& (async-shell-command) instead of running it in a shell buffer. Long lines are a more general issue with Emacs, but there's changes in Emacs 27 that should mostly solve it.
- pmoriarty 7y ago"that hasn't come up for me very often" The fact that it can happen and does happen leads me to avoid Emacs' shell modes altogether. I just don't want my Emacs freezing on me ever. Considering how much I do in it, it freezing on me is an utter and complete disaster that I want to completely avoid even if it doesn't happen often. "there's changes in Emacs 27 that should mostly solve it" If you're talking about the solong mode integration, that's just a hack that kind of works for static buffers, but won't help in dynamic buffers like shell-mode. To really and truly fix this issue, a core part of Emacs will have to be rewritten, and since that part is written in C and is pretty hairy, no one seems to want to deal with it. So it probably won't happen any time soon. I'm just hoping Emacs' libvterm integration provides a good workaround, at least for using a shell from within Emacs. I'll have to give it a try one of these days.