From Vim to Emacs
juanjoalvarez.net
juanjoalvarez.net
Fast-forward to about 4 months ago, and I thought: "My vi-fu isn't at the level of my emacs-fu", so I gave myself an 8 week challenge...
If anybody were to ask me "should I learn emacs or vi?", an appropriate answer would be "yes." They're both awesome, and you can learn both. Go for it.
Emacs with evil, without a doubt, runs so much smoother while editing large projects. The biggest point is that asynchronous operations are a lot easier to perform in emacs. You can get close to it with plugins like vim-dispatch or vimproc, but they always felt like a second class solution to me.
You get cool stuff like search/replace preview and super smooth async operations in the background (like on the fly linting with flycheck).
In the end, I'm still using vim. Unite with vimproc is "good enough" for me. For me, the only real place where async operation is a huge problem is with file search operations. Every few months I try to use emacs for a day, maybe next time it will stick :)
I think the snippet of code in linked article in section 'Escape . . . escapes things' fixes most of the situations where you'd get stuck in a non-Evil mode in Emacs. It's a must have for me, otherwise I too got frustrated with getting stuck in Emacs minibuffer/command line and <esc> not getting me back to Evil-mode in main buffer. I also turned off the bell in Emacs, which helped psychologically.
With emacs, it seems like I have to learn the system to even use some plugins like projectile effectively.
The least you should do is the tutorial that's presented on the startup screen or "M-x help-with-tutorial".
The reason I've seen mentioned by the author is to learn the other tool, in this case Emacs. But for that I think the smarter way would be to learn to use Emacs like Emacs users do it. There's a reason why things are implemented differently, right?
You're attached to modal editing but you want some of the Emacs plugins and a less terrible scripting language.
That was 2011. I've been an emacs user ever since.
Conclusion: neither is better. I think.
Jokes aside, during the 1 or 2 weeks that I forced myself to use emacs (a few years back), I felt that I would get RSI because of the painful default keybindings. Of course, I didn't know of evil back then, so I returned back to using vim.
So my question: How does Emacs and Vim compare speed-wise? I come from a Sublime Text background and really miss the ability to quickly navigate between tabs (buffers in vim), and sometimes it takes a full second.
Normally vim is very snappy for me. Perhaps you have a ton of plugins that are clogging up your installation? Or perhaps just one very badly behaved plugin?
I also use Janus https://github.com/carlhuda/janus so i might be a victim of improvements made by them.
Speed is the #1 reason I switched to Vim
I hear this a lot, and I'm not debating whether it's true or not since ymmv. I'm curious if anyone here has gone the other way.
I used vi in my teens then switched to emacs, which I used for over a decade. A couple years ago I switched to JetBrains IDEs and have never been happier. I hadn't used an IDE since Borland Turbo C, and forgot what I was missing.
Are there any other former vi/emacs users (like, hardcore - I used to browse the web in emacs) who ditched it for an IDE?
I found that the mouse really wasn't a productivity killer for the few times you need to use it in a modern IDE.
I've used both emacs and vim extensively, but have never "ditched" either for an IDE. However, what I have found is that in some dev environments I'll use the IDE as the primary editor. IDEs at their best have great tools for maintenance, navigation, and comprehension of existing codebases. But when it comes time for e.g. many kinds of textual heavy lifting or whole-cloth new code I'll switch right over to emacs/vim.
FWIW, I'm really hoping that the long-term architectural changes in neovim will open the door to first-class IDE style feature sets. There's definitely been some good work that way in recent years, but those efforts are often hobbled by the classic editors' long legacies.
I imagine there are some plugins available for vi and emacs that try to provide these features, but I would guess they require some configuration and won't work as reliably.
C++ has always been had issues but for me it's good enough especially since I move between languages and OSes a lot. If I was just doing C# on Windows I would probably use an IDE tuned for it.
When I was working at a .net shop, VS became my vim (mostly because it was already always running), also because it was incredibly familiar.
Since leaving the .net world though, I've relapsed. Have had trouble with eclipse|intelli-j|etc due to their general java slugishness on the mac.
http://www.amazon.com/Practical-Vim-Thought-Pragmatic-Progra...
A whole book of tips
I'll only use an IDE for languages that rely heavily on code completion, and have good support for it through static typing and libraries that include symbol tables. In practice, that means Java and C#.
In those cases, I prefer IDEs with some kind of Vim emulation over Emacs.
Other environments are less restrictive, and projects often come down to just a bunch of files in a git repo. This is where text editors shine. I consider this a language feature of sorts.
I'm an active vimmer very involved with the community and, for me, using an IDE or Vim is not a political/religious/philosophical choice: it is a pragmatic choice. When I need IDE features I use an IDE, when I don't I use my favorite text editor. Simple.
> I found that the mouse really wasn't a productivity killer for the few times you need to use it in a modern IDE.
"Modern" IDEs expose all their functionalities via keyboard shortcuts so you don't really need the mouse.
Whenever I have to use Visual Studio, the VsVim extension gives me the best of both worlds.
Yes!
I also started my IDE days back in Turbo Pascal. Used most of the Turbo Pascal, C and C++ versions of Borland products up to Delphi early versions.
Thanks to some friends I also knew from seeing, not really used them, a few Amiga IDEs like DevPac.
When I started using UNIX, initially Xenix followed bz DG/UX and many others, vi was all there was available to us.
Eventually I found Emacs and it became my UNIX editor between 1996 and 2005. With vi playing the fireman role when nothing else was installed.
However UNIX wasn't the only system were I had to work on. So I became acquainted with Smalltalk and Oberon environments as well.
In the end, I kept always looking to replicate IDE experiences on UNIX systems. But never found one at the same level of experience than what the PC world had to offer me.
As my work became more focused in JVM and .NET land, I left Emacs.
Emacs might have been a great editor back in the day, but IDEs have so much to offer. Even if one can spend weeks coding ELisp code for the said functionalists they aren't as well polished nor as functional as what IDEs offer out of the box.
> I found that the mouse really wasn't a productivity killer for the few times you need to use it in a modern IDE.
If one masters IDE shortcuts + mouse, I feel productivity is like playing a FPS against someone just using the keyboard.
I don't regret buying it, but after some time I realised that it's impossible to replace Emacs completely with PyCharm.
PyCharm's support for refactoring and code transformations is very good. It's fast and easy and it makes some kinds of source code edits much more efficient than what you can do even in Vim and Emacs. Its debugger, including remote debugger is very good, too. Visualising project and file structure in a sidebar is much, much better than what Speedbar and ECB (at least for Python - I heard they work very well for other languages) can do. Codebase navigation is nice (go to symbol, etc.), although Emacs with all its tools like jedi, ag, e/ctags, occur, imenu and so on is not that much worse here.
PyCharm is very good for working with code. However, it lacks so many text editing features, that it's just too painful for me to use it exclusively. Even with many plugins installed and multiple cursors feature provided (recently - how could it take them so long to implement it?) text editing experience in PyCharm is much worse than it is in Emacs (or Vim, for that matter). And, unfortunately, working with source code is in large part the same as working with plain text.
An then there's a problem with extending PyCharm. The need to write Java code to extend an editor seems like a really bad joke. There are plugins, which let you script PyCharm with Groovy or Clojure, which I installed, only to discover that the Clojure syntax highlighting plugin for PyCharm doesn't work right now. Discovering the relevant APIs to call from a script was a major pain, too, compared to Emacs built-in combo of info manuals and help system with apropos and many reflective commands like describe-*. This is a problem, because using Emacs made my tolerance for putting up with broken/inconvenient behaviours disappear - many things I know I should be able to achieve in two keypresses in PyCharm take 3 or 4. That's not a big difference and I realize it! Yet after working with Emacs and writing ~5k loc of Elisp to scratch almost all my daily itches I just can't force myself to just ignore it and get used to this itching again, even if it's minor.
My solution was to create a quick keyboard shortcut in PyCharm which calls emacsclient with current file, placing the cursor in a current line. Surprisingly, it works very well. Launching a new Emacs frame takes almost no time at all, and when I close the frame after editing, PyCharm immediately displays updated content.
I wonder if the redraw issues were the fault of your terminal emulator rather than vim. I don't have a lot of MacOS experience, though.
When switching via ctrlp everything is instantaneous, but that requires more commands than just C-k or C-j.
That disables all initializations from your .vimrc, plugins, etc. so you can see how fast "vanilla" vim is.
Launch macvim as `mvim -u NONE --noplugin` and see if you can still reproduce your speed issues. If you can't, then your problem is not with vim, but with a plugin (or with your ~/.vimrc).
You can use bisectly[1] to do a binary search over your installed plugins looking for a faulty one. This is similar to how git-bisect works, and it's WAY more effective than disabling your plugins one by one. I've personally used repeatedly it to narrow down problems to vim-gitgutter, which is quite possibly the buggiest plugin I've ever used.
run :profile start filename, then :profile func * Then do the slow thing, and close vim. This will write your profile data to filename.
- in non-evil-mode at least, C-x C-x will reselect what you last pasted if you haven't moved. What really happens is that when you paste, the "mark" is set there (equivalent to doing C-SPC), and C-x C-x will switch point (your cursor) and the mark.
However, if you want a function that works even after you've moved around a bit you could do e.g.
(defadvice yank (around advice-yank-set-vars activate)
(setq yank-last-start (point))
ad-do-it
(setq yank-last-end (point)))
(global-set-key (kbd "C-c C-y")
(defun select-last-yank ()
(interactive)
(push-mark yank-last-start)
(goto-char yank-last-end)
(activate-mark)))
I can highly recommend Bozhidar Batsov's Emacs Prelude[2] as a nice foundation for building a personalized configuration. Just fork it and put your personal .el files under the "personal" subdirectory; then "git fetch ... && git merge" to keep up to date with improvements committed to the author's repository.
I think my approach re: prelude is a bit cleaner. See this: https://github.com/mahmoudimus/.emacs.d
This allows an easy to back up to github while still maintaining easy update access to prelude.
http://nathantypanski.com/blog/2014-08-03-a-vim-like-emacs-c...
Bling, who I've linked to in that post, has repeatedly made quality posts about making the transition:
Here is my prelude customizations:
https://github.com/humana/dotfiles/blob/master/emacs/persona...
I'm quite proficient in both editors and while I resort to Emacs for 95% of my coding (and mail, and notes, and agenda, and...) sometimes nothing beats the simplicity of firing up vi for a quick edit in a remote server.
Using vanilla vi with a minimal to non existent .vimrc can be liberating.
What's amusing to me is how many people don't know vi very well and use plugins in vim that vi can handle as well or better through macros, ex scripts or external commands.
I don't know where this practice comes from but it feels exactly the same as when people say Unix when they are very obviously talking about GNU/Linux.
These actions make the two interchangeable in people's minds.
Personaly: I try to use my console editors as vanila as posible so that I can feel right at home directly. Kind of the exact opposite of this :)
Plugins in vim are usually pretty poor compared to emacs, and vimscript is frustrating. Emacs Lisp is at least a consistent language, and one that I can figure out how to use much better.
-- to get all that juicy goodness that is the emacs environment, that's why. Emacs is far from perfect, but there are a lot of things to like about it -- especially if you want to interface with Lisp or Lisp-like environments (Common Lisp, Scheme, Clojure, etc). Emacs does a better job of interacting asynchronously with other processes -- which is one of the reasons it is better for use with Lisp-like environments.
I've used vim for over 15 years, and I still use it daily, but I prefer the emacs/evil environment for anything where I want to interact with a repl from inside my text editor.
There are another similar sites?
Two things comes to my mind when we talk about emacs and other editors.
The Terminal! In particular iterm.app
Basically with iterm and vim, I'm on osx close to a i3 on linux.
Vim works perfectly inside a terminal (no need to remap meta). We have terminals on android, ipad etc...
I love working in a terminal because... well, is where I spend most of the time. Running ruby, compiling go, js, logging on a server, running a script, tailing logs...
[1] loser because my vim is "modern" so with mouse, arrows and so on...
The only problem is terminals. You can run them inside of Emacs, but there's always issues. You can run eshell[2] which is wonderful. Myself, I prefer to use terminals outside of Emacs.
[1] my development OS is Linux and I run i3
[2] http://www.masteringemacs.org/articles/2010/12/13/complete-g...
Tried for 10 minutes and found out it has not g-/g+. (still awesome)
And vice-versa.
Since he appears to be on Linux, another way to solve this issue is to use a terminal that supports 256 colors. urxvt and Xterm both have 256 color variants.
Software developers spend hours every day writing code, dozens of hours each week, hundreds of hours each year. It's only natural to care about the tools you spend hundreds and thousands of hours using.
We talk about vim and emacs so much because they are the most powerful popular editors, in terms of being flexible and customizable. There's a limit to how many "editor workflows" one can use with Sublime (though Sublime is great) or Visual Studio or XCode or whatever. Not so with vim and emacs. They both also have decades of plugins and hardening. It's only natural that developers who prefer OSS and jump around amongst different languages and platforms would gravitate towards vim and emacs.
Those of us who love one of those two editors (vim, in my case) are often very curious to see how the other side lives, what workflows they use, etc. That curiosity is a great thing. Trying to improve your skills is a great thing. Stop complaining about it.
If you don't care or maybe used to care but are now soooooo over it, then just don't freaking open the comments, right? This topic is totally germane to HN and interesting to many of us.
Either way, I use vim, and, as a result, I have to listen to pro-and-con debates unwillingly... all the time. At the time, this was an example.
In actuality there is no right answer to what browser is best. Personally, I think vim is fast and easier-on-the-hands than emacs. In particular, I never have to lift my hands from the main row, where in emacs I too-frequently have to press combinations of keys and shift my positioning.
This all comes from someone who originally used emacs, then converted to vim.