From Vim to Emacs in fourteen days (2015)(blog.aaronbieber.com) |
From Vim to Emacs in fourteen days (2015)(blog.aaronbieber.com) |
(Vim user for 23 years, Emacs user of none... but interested because of Lisp)
I still use vim when I am at a new system or on a remote server, but Emacs is love, Emacs is home. It is the most open, discoverable and hackable software system I have ever used. Every action, button, keybinding is easily introspectable - and it takes only a few clicks to get even to the source of the functionality that you are interested in. Almost every aspect of this system is modifiable by the user, even on the fly.
The only downside is that it is so much fun to play with your emacs config that you might spend too much time doing that instead of productive work. By contrast, vimscript is so disgusting that I don't think that I ever wrote a single line of vim config that wasn't copy-pasted from somewhere.
A couple years ago during a lull in a dev cycle I built a neovim setup to see the state of that art but I didn't stick with it.
I've rewritten my emacs configuration many times, swapped between spacemacs, vanilla, and doom. I am currently on doom emacs with my customizations.
I also do not use evil mode anymore. Default emacs bindings make a lot of sense to me. I can still use vim with muscle memory, but I reach for "mg" if I need a quick edit more often than not.
I'd like to give emacs one more chance, but haven't gotten around to it. Last time I tried Spacemacs (for about a month, sorry not a year) and ultimately didn't like it, I'm planning on trying Doom Emacs next.
I agree. For those who are interested in using Vim as their development environment for Common Lisp, I have written a detailed comparison between Slimv and Vlime here: https://susam.in/blog/lisp-in-vim-with-slimv-or-vlime/
And for those who are willing to start Common Lisp development using Emacs, there is Portacle which is a really quick way to set up a working environment with a few clicks. There is also https://github.com/susam/emacs4cl that I wrote to offer as a quick-starter DIY alternative for those who want to use vanilla Emacs and want to configure it themselves without wasting too much time.
I have gone back and forth between vim and emacs, usually for a bunch of years each time before currently settling on emacs with Doom. With the nativecomp branch, it's actually pretty snappy and doom emacs is a great setup to get started without drowning in the amount of configuration.
I would say that I just love vim style input and modal editing, but doing that on top of emacs with evil mode and elisp is a better match for me than vimscript. The feedback loop you get with LISP and emacs is incredible when tweaking things to your liking.
Every function is accessible, there is just a global scope and you can call pretty much anything. It's sounds like an horrible idea, but it also means you can quickly hack stuff by reusing the internals of a package you like.
For example, it took me half an hour to initially POC this https://github.com/jhchabran/ivy-lsp-current-buffer-symbols by just skimming through the emacs-lsp codebase and randomly trying funcs in the repl to get an idea of what each function was doing.
Vim user for ten years after college with a couple of forced dips into Eclipse and other IDEs, with vi keybindings where available.
Evil emacs user for about the last ten years. Magit makes me happy. Tramp wins the "but vi is everywhere" conversation. Org-mode wins.
I won't hire someone unwilling to give emacs an honest effort. Switching back to emacs remains the best professional decision I have made.
An employer has no business dictating what text editor their employees use, if they're productive.
I am glad I took time to learn vim. The editing concepts around motion keys, text blocks etc. are just so much more powerful than emacs way.
I recommend all emacs users to learn vim atleast give evil mode a try.
How to go from Vim to any other Editor/IDE and use Vim bindings ...
WordStar ought to be enough for anybody!
True, but only because Emacs is older than God :-)
(They say they used parenthesis, but it was just snippets of Perl everywhere: https://xkcd.com/224/)
In the beginning was the lambda, and the lambda was with Emacs, and Emacs was the lambda.
After over a decade of Vim, I’m hooked on Emacs - https://news.ycombinator.com/item?id=16551796 - March 2018 (161 comments)
A pragmatic decision on GNU Emacs versus Vim for programming - https://news.ycombinator.com/item?id=13590944 - Feb 2017 (59 comments)
Why I switched from Vim to Emacs - https://news.ycombinator.com/item?id=13130775 - Dec 2016 (101 comments)
From Vim to Emacs - https://news.ycombinator.com/item?id=8367384 - Sept 2014 (116 comments)
Emacs and Vim - https://news.ycombinator.com/item?id=8084359 - July 2014 (275 comments)
Vi and Vim vs. Emacs Shootout and Deal - https://news.ycombinator.com/item?id=3205828 - Nov 2011 (52 comments)
Some thoughts on Emacs and Vim - https://news.ycombinator.com/item?id=2229040 - Feb 2011 (40 comments)
How a Vim user converts to Emacs - https://news.ycombinator.com/item?id=2036586 - Dec 2010 (66 comments)
On vim vs emacs - https://news.ycombinator.com/item?id=1374916 - May 2010 (28 comments)
Debian's Vim maintainer switches to Emacs - https://news.ycombinator.com/item?id=341492 - Oct 2008 (32 comments)
No shade on Vim, people like it and are productive in it. I see it like using Sublime Text, lots of people can get away with it, but I need more doodads in my editor.
And hey, nobody is like "Notepad++ vs. Visual Studio", which I think kinda matches the mismatch (or maybe "Notepad++ vs Atom" or something)
In 2001, Slashdot held a poll for Best Flame War. [0] The winner, by quite a margin, was Operating System, but the text editor wars (presently being fought at [1]) weren't listed as an option. Personally I'm also rather fond of the tabs-vs-spaces debate.
>> Debian's Vim maintainer switches to Emacs - https://news.ycombinator.com/item?id=341492 - Oct 2008 (32 comments)
He warned me I should switch from vi to emacs because prolonged vi usage causes hair loss. :)
But when I got a gig as a sysadmin running a few thousand servers w/ a slew of Unixes (Solaris, BSD, HP-UX, Linux) I finally bit the bullet and learned vi, because it was the only common denominator (oh, man and ksh88 because so many bash-es were so broken on those platforms).
Now I find modal editing very natural and productive and don't miss the keyboard gymnastics of emacs. I find I get pissed at every text editor that isn't vi. Outlook, this text box, etc.
I use IntelliJ (and do Python and Go in it) with vi binding for large long-lived projects and just vim/neovim in a terminal for scripts, short-lived stuff, and quick edits. The bindings in IntelliJ are good enough, although sometimes I forget and try to do things, like run a file through awk.
I play with using VSCode with vi bindings from time to time, but honestly just forget to use it much.
I have a smallish vim config with a handful of plugins, mostly for linting. I'm comfortable with it and haven't ever really found it lacking. And I don't feel the need to maintain a codebase for my config like I enjoyed doing in college. I guess I garden in my garden vs my config files and am not so focused on some kind of concept of purity. Heck, I think I have the default background on my mac.
Org-mode and configuring emacs in a lisp-like are cool, but are not worth re-learning everything for me. I put that time in already by reading "Practical Vim" by Drew Neil and other vim literature online. I'm sure everyone is already aware, but vi is available basically everywhere. This has saved my ass at least twice where I couldn't access vim or had internet access to install XYZ editor.
So as a power vim user I see no reason to switch. If I can't use vim, most editors now have support for reasonable vim bindings. So I use that for Jetbrains' products / Joplin / Insomnia / etc.
Partly because of excellent plugins (VSCode, Visual Studio), partly because, for some reason I bothered to learn Vim shortcuts to degree I never did with Emacs. And I just love that vi and vim is quick and available on my various cloud servers.
Once in a while I toy with the idea of going back and using evil mode (I keep reading about org mode).
You don't need to install emacs on every computer you use. The emacs on your laptop has tramp so you can edit any file on any computer you have ssh access into.
I like org mode a lot. It has a lot of functionality that makes it useful for all sorts of things beyond plain text editing. Using evil meant I didn't need retrain for common editing operations, although certain org-mode specific functionality means learning new Emacs-style key sequences.
Other than that, I still haven't learned anything about using plain emacs, so I only use emacs for editing org files. They're a different enough entity from ordinary text files that switching editors to use org mode doesn't bother me.
Can anyone recommend a resource? I speak some C-like languages, and Python and Haskell, but no LISP at all. I'm an emacs user, but have only superficial knowledge of how emacs actually works.
https://emacs.stackexchange.com/questions/47318/how-can-i-st...
(I've been cluelessly hacking at emacs for decades, and there's ALWAYS something new to learn.)
So curiosity rather than conversion. Six year later is he still using Emacs? Went back to Vim? Moved on to something else?
I have enough years invested in muscle memory of Vim itself and various plugins that what curiosity I have about Emacs is well controlled. I doubt I have runway left to get to the same productivity in another editor.
I had the same fear before switching to emacs(in evil mode), so I changed some of the default shortcuts that I was accustomed in vim(e.g. nerdtree/treemacs). It's not that hard.
The whole enormous productivity boost that you get from Org mode(and org babel/literate programming) is well worth the temporary minor inconveniences of learning the tool.
He was as of Jan 2020.
It has "evil mode" by default — the vim bindings.
I picked this up at Jane Street, where much of the internal tooling is in emacs. I still use it wherever I can't get a good vscode setup, and it has some advantages over vscode.
I wish someone had told Doom about it before I picked up spacemacs so maybe this post will benefit past-future-me.
Simple Make fails on linux out of the box.
And the look&feel and features are very far from emacs.
Maybe it's because I'm not a "touch typist" who uses a home row and all that stuff, so the keybindings optimized for that don't really help me that much.
I do like Vim though, and it's an insanely useful skill to have because I can SSH into any server and edit config files like if I were straight up programming.
While today I dont't use Emacs as the day-to-day editor (I use VSCode, for a bunch of not entirely good reasons that mostly have to do with macOS) I think that exposing people new to unix to emacs/zile makes more sense than to vi(m). And then there is the "every mac textfield understands default emacs key bindings" effect...
Does anyone know where I could find more info about this stuff?
Does anyone know of any research comparing the efficiency/speed/stress of VIM users to, say, VS Code keybindings or emacs ones?
I am a productive vim user already and have just learned standard emacs bindings and ergoemacs bindings within a few hours. This is not a matter of a vim-naiive person avoiding learning the tool. I do have a preoccupation with tools rather than getting stuff done with them... That's our curse isn't it?
Because Vim and Emacs are two distinct categories. The only thing that makes them similar is that they are both based on something. That something is an idea. And not just an ordinary, everyday concept, but an influential, holy grail type of thing.
Vi and the concept of the modality is an incredible, powerful, fantastic model. People who never hardheartedly tried to learn Vi-model just don't get to say anything about it. Can you respect an opinion about CRISPR coming from someone who has no clue about polynucleotide chains and DNA?
Yes, Vim is not overly intuitive for a complete beginner. Like many, perhaps most awesome tools, it too has a certain level of sophistication. You cannot enter the Suez or Panama Canal gates' control room and suggest removing all those knobs, switches, buttons, etc., and instead, install one colossal touch screen because that would be "a much more intuitive interface".
Vim is hard to learn, but you see, there's usually a strong correlation between something that's not so easy to acquire and simplicity gained later. Conversely, things that are easy to pick up, very often later become cumbersome and annoyingly counter-productive. Rich Hickey's "Simple Made Easy" rhetoric very nicely manifests that.
So yes, Vi-model is an incredible idea. Vim, Neovim, Evil, etc., are just implementations of that idea.
Now, Emacs is based on another mind-blowing idea. The idea of practical notation for lambda calculus, what is known as Lisp. Lisp, probably can be crowned as the most important idea in computer science. It's just hard to think of something more influential than Lisp. Emacs is just a practical implementation (and frankly, not the best one) of that idea.
Arguing what's better - Emacs or Vim is like debating what was more important in the history of health care - the invention of anesthesia or discovery of penicillin.
Both Vim and Emacs are awesome, and one is not better than another. If you can't see that - then probably there's a big hole in your understanding of at least one of the ideas they are based on.
Except that I don't have any other use for Emacs.
- if you are on osx, you'll may find the gui rendering quite laggy if you are using a Retina display. Using the terminal will make it snappy again. Using something like Alacritty will make it even snappier if you're sensitive to it.
- if you are on linux and use the gui, the pgtk branch is worth giving a try, it drops the old extremely outdated Xt code
- LSP can be quite resource hungry, it's really worth giving a try to the nativecomp branch of emacs 28. https://www.emacswiki.org/emacs/GccEmacs
Anyone use this regularly? Does it kill off some of the upside of emacs?
Personally, I mostly just use evil for modal editing, as I am a long time vim user. Then I use the emacs shortcuts on top of that.
Also, if you enjoy the experience provided by emacs + evil, giving a try to the native compilation branch of emacs 28 gives noticeable improvement in terms of speed.
[1] Spacemacs "it's a sophisticated and polished set-up, focused on ergonomics, mnemonics and consistency" VS being focused on speed, https://github.com/hlissner/doom-emacs#introduction
I always keep a GVIM window open so that I can type text there and then paste those into other places that are not vi.
It also helps that vi is a lot more stable than certain websites and is less likely to lose my text. It's nice to be able to just copy&paste without having to re-type the same text when browser crashes.
:)
Essentially, I get modality when I want an interface. And the rest of the time, I type.
I still make sure that I know good-enough vim and nano so I can do what I want outside of my own environment.
If some text is selected before invoking undo, then undo happens only within the selected region.
If I were to hazard a guess: zero. That was also me during ten years of vim usage. Vim encourages the mindset of mastery = learning a bunch of tricks, remembering them and incorporating them into muscle memory.
Emacs on the other hand encourages the mindset that my editor is a programmable tool, I am a programmer, I can make it do whatever I want. You are always just one click away from the source code implementing any functionality of your editor, which you can, if you choose to do so, modify and evaluate on the fly.
> vi is available basically everywhere
Emacs-like shortcuts are also available wherever you have readline (e.g. many shells).
>This has saved my ass at least twice where I couldn't access vim or had internet access to install XYZ editor.
In those situations, I also still use vim. But 99% of the time, I am not on some remote machine, I am on my personal computer, so I can choose to use a tool that is not installed by default. The basic vim commands I have internalized over the years are sufficient for those odd jobs.
>So as a power vim user I see no reason to switch.
To each their own. Personally, I think that Emacs is a much more rewarding tool to master.
>most editors now have support for reasonable vim bindings
So does Emacs :)
In fact Emacs' vim plugin is probably has the most feature rich of all the vim emulations.
Neovim also supports configuring your setup in lua, certainly a better language than vimscript (which I agree isn't great) and lets you write native neovim plugins in lua.
Emacs of course supports LSP (and probably treesitter), I'm just reflecting on the fact that (neo)vim continues to evolve.
I think without neovim, vim popularity would have continued to degrade. Though the community, especially with packages like Coc.vim, continues to push vim along and bring support for external features. I personally think neovim is the future over vim given its management and native support for LSP and Treesitter.
In either case, its awesome both editors are still going strong! While VSCode and JetBrains' IDEs are great, they always feel crowded compared to vim. I love that both (neo)vim and emacs still have such large communities behind them. Both are great examples of software that is old, receives improvements and evolves, and continuously delivers value to their users.
And also, the syntax is shared with other Unix tools like man, less, sed, etc.
I'm not saying Vim is objectively better than Emacs or anything, but the basic commands gg, G, d$, dd, y$, yy, ^, $, and so on really are handy as a tool.
(Also worth noting that the syntax has overlap with Regex, so "^" and "$" are very natural choices for commands that jump to the beginning and end of the current line.)
Zero, thank god. I have enough work to do at work. I don't need to make a hobby out of my editor.
Well, I haven't had a real reason to do so. I used to use more plugins but I slowly am paring it down to a much more minimal configuration. I'm not a huge fan of vimscript, but I don't think it's worth changing over to emacs for. Plain vi actually isn't that bad, depending on the version.
"Emacs-like shortcuts are also available wherever you have readline (e.g. many shells)."
Sure, and I appreciate the irony of learning some emacs shortcuts for readline while using vim. But that's different from editing. The only time I've seen vi not available is in scratch/alpine linux containers where busybox essentials weren't installed either.
I suppose my use case is different because I work a lot with containers, and minimal install systems in general.
Sure there's all the regular Emacs value-adds (Org-mode, Magit, TRAMP etc.) and there's no rush to start learning them, but navigating local/remote codebases all the while treating Dired filesystem views, regular files AND terminal ptys as buffers with full modal editing I find to be something of a special power. This has been possible for a long time with eshell/shell etc. but vterm really takes the lag out of it IMO. This workflow was certainly my gateway drug to Emacs. It displaced nearly two decades of vim for editing and tmux for terminals. YMMV.
[1] I wrote a bit about the workflow and continuing to train better with vim bindings using Emacs https://martin.baillie.id/wrote/evil-motion-training-for-ema...
Wait... wait... vterm works with TRAMP? How?
If this lets you navigate remote filesystems as in eshell without the lag on each command that results in... I'm sold.
EDIT: Oh, I found https://github.com/jixiuf/vterm-toggle which seems to open a vterm pane and ssh into the remote host. Which is close enough, I suppose! (Though I would miss being able to just `cp` from a remote path to a local path as if they were both local.)
I prefer vim for everything else and the general "minimalist" approach in particular. Emacs seems to appeal to people who like to do everything within one tool.
I've recently switched my "notes.txt" buffer in (neo)vim to markdown ("notes.md) - along with a slightly more magical syntax plug-in - and I'm pleasantly surprised by the quality of life improvements from having multiple code/script snippets highlighted in-line (eg: ```SQL (... Snippet...) ``` in a paragraph followed by some notes and a block of bash etc).
But I rarely execute the blocks in / from vim - I do a bit of copy-pasting though (I don't generally fit a terminal buffer/window in vim, I use a separate window with gnome-terminal or Sakura. I tried term-in-vim, but didn't quite like the flow. Maybe I should try again).
In other words it does one thing, hopefully well. The philosophy behind the original vi, and IIRC originally vim too — didn’t it previously have an explicit non-goal of adding an embedded terminal emulator? If it did, those days seem over, so you IMO you might as well use an editor that does many things well (eg. having a proper designed language as the default for configuration, not the bodge that is vimscript with Lua as just a secondary option ), if you’re going to use an IDE and not an actually minimal text editor like vis or sam.
Fortunately you don’t need to ‘re-learn everything’ with evil-mode. I doubt other editors’ support for reasonable vim bindings is as complete as the common base of Spacemacs and Doom, they certainly aren’t as complete of operating systems, capable of being your WM (EXWM) or your init system or shell (http://www.informatimago.com/linux/emacs-on-user-mode-linux....), nor capable of running in a terminal over ssh.
For me the main reason I prefer emacs is the key bindings are better.
Another reason that emacs (the real thing) is available everywhere. You can install it on Linux, Mac and Windows. And you can run it in console mode (terminal) as well as GUI (even on Windows).
Genuine question, why do you think emacs key bindings are better?
emacs has good vim emulation through the evil package.
Doom emacs, is a decent place to start for a vimmer.
So, once you learn a vi command, you can use it with all the motions you already know, and once you learn a motion, you can use it with all the commands you already know.
The other aspect, that is more insidiously useful: vi is almost everywhere, and will easily fit on an embedded system. It's a rare server that doesn't have it, either. This is definitely vi, not vim, when I say this, though.
Command mode lets you manipulate text using a full keyboard as shortcuts. Depending on setup this can reduce the amount of chording you do.
Visual mode lets you select text. By character, line, or region/block. I find this easier than emacs selection.
Insert mode what you use to enter text.
Emacs' evil-mode is used by many Emacs users who prefer modal editing...
After a few weeks of fighting it, I switched to evil-mode emacs and was pretty happy since then.
I have been using a jetbrain IDE recently and surprisingly, the vim plugin is pretty decent. So knowing vim lets me use both the IDE and emacs with less friction.
(edit like a timelord!)
I don't feel like I'm missing anything from a VIM-only setup in any way right now
Emacs and Vim aren't quite like that.
If I'm actually developing something that's part of a greater whole, then I'm using a fully fledged IDE like PyCharm (but with the VIM emulator plugged in for when I need it, of course ;-D).
Likewise, no shade at Emacs, though. Several of my favorite colleagues use it!
* TRAMP for remote editing. It's more powerful than Vim's netrw remote editing capabilites and can handle root-owned files on remote servers. It's so extensible there's even a package that allows you to edit files inside Docker containers running on remote servers.
* Dired. It's the best text-based file manager out there IMHO, and it integrates very nicely with TRAMP.
* Org mode. It can be used like Jupyter notebook, but is far more powerful. You can write each code block in any language you choose, pass data between them, and make each of them run on different servers. This is very useful for sysadmin tasks especially in professional environments because it allows you to document each step in a reproducible manner as you're executing it. You can then just share the org document for your cowokers to review.
I personally use Vim for coding and Emacs for non-trivial sysadmin tasks.
"set incsearch" is all it takes to get incremental search. Are you trying to argue that Emacs defaults are so good that you never need to change it? I find it hard to believe you never have any "setq"s in your Emacs config.
> In emacs you can type to search then ctrl+s to move to next match then continue to type to edit the search string
In vim you can type to search then n to move to next match then /<ctrl-p> to continue to edit the search string. But seriously, a fuzzy searcher or :grep would be more useful for that sort of thing.
> Replace has advantages in emacs when it comes to case matching.
Case matching is a thing with Vim's regex too.
> And it goes on and on.
But all of the things mentioned so far are about basic editing capabilities that any decent editor would support one way another.
What do you mean by “type to search”? Sounds like you’re omitting the “start search” key combo.
Your example in Vim:
* / to start a forward search
* type in the word and hit enter
* n/N for next/previous match
To modify the search:
* q/ opens your search history with the cursor at the last searched string
* modify the search string using standard Vim keys
* hit enter to search
That's the problem. When you hit enter you have left incremental search. In emacs you can refine the search string without leaving. Ctrl+s and Ctrl+r goes prev/next and you can simultaneously refine the search string (by typing any other char) without leaving incremental search. Given how important search is (for a programmer) this alone is worth the price of entry. But there are many more things.
Until you need to ssh into a server and edit something.
https://www.murilopereira.com/how-to-open-a-file-in-emacs/
The summary is that the author tried to open a remote file and Emacs froze for several seconds. He dived deep into finding out why that was and how to fix it, pointing out how great Emacs's introspection is that one can find solutions to problems like these.
And then two thirds of the way into his essay, he has this:
> More recently, I’ve been very put off by the performance and stability (or lack thereof) of building large scale software via Tramp. This has been sufficient to have me looking out again. On a whim, I installed VSCode for the first time and tried its “remote development” capabilities and holy smokes are they good. Getting up and running was trivial and the performance was great. Saving files was snappy and LSP worked out of the box. What a different experience from my carefully-put-together, half-working, slow Emacs setup.
And then later:
> Improve Tramp performance to match the experience of using terminal Emacs via SSH, or VSCode’s Remote Development.
(Incidentally, I don't even use lsp on Emacs, although I may give it a try).
Also the remote extensions are proprietary [1]. This has been discussed on HN before.
They did not embrace LSP. They invented it. LSP came from MS.
> And pylance might become the defacto python LSP.
Nothing is preventing someone from creating another python LSP that will work with the LSP tools. MS is not unique in this. Jetbrains makes proprietary products that are well embraced by the Python community.
Thanks, today I learned.
Yeah anyone is free to create, same as anyone is free to create remote extensions for VSCodium. So far nobody seems to have done it. Even if somebody does it, it might not match the quality and features of MS extensions.
MS has a history of EEE. Jetbrains doesn't, and as far as I know they are no bullshit no dark patterns high quality.
If one is concerned enough not to use VSCode because it is MS, then one should also not use LSP.
I don't think this changes the issue: EEE became CEE (Create, Extend, Extinguish).