I began using Vim about a month ago and it has been totally revelatory to me, and believe quite honestly that it was the best career decision I've ever made. The one thing, however, is its speed. MacVim gets very slow sometimes, particularly with buffers.
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.
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.
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'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 am not the person to whom you replied, but the feature I use most often in Xcode is Go To Definition (with command-click). This integrates with clang, so it knows how to navigate templates, overloads, etc. It also integrates with the build system, so it knows the correct header search paths, preprocessor macros, etc.
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.
Whether they work as reliably depends on the language. Emacs + Slime for Common Lisp is fine. Nowadays there's luckily a lot of editor / IDE independent tools like Jedi, ycmd, eclim which improves the situation for Emacs and Vim considerably.
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.
I find that it depends on what kind of languages you work in. Boilerplate-y languages like Java require way too much hand-holding to be nice to do in an editor. On the other hand, Haskell/OCaml in Vim are fairly nice with the right plugins, as long as you don't mind refactoring via sed.
For "go to definition" I use either ctags or cscope. Cscope can work as a front-end and launch -whatever- editor you want. In nvi, I have good interfaces to both cscope and ctags, and I believe most vi clones have ctags interfaces, and emacs has etags.
Power vim user for 7+ years, then started using org-mode in emacs and eventually got sucked in and did everything in emacs for a while... then needed to do Android dev, ended up really liking Android Studio, realized all the JetBrains IDEs are amazing. Now I'm spending my days with Android Studio, AppCode, RubyMine, but still using org-mode in emacs. Never felt right with evil mode, but the vim bindings in all the JetBrains IDEs are good enough. I'm not going to let terrible support for visual mode multiline insertion ruin my day. There's a place for all these tools and eventually you're going to have to touch a lot of them. I'm really happy I respected them enough to invest some real time.
I went from RubyMine to emacs, for working with rails / coffeescript projects. Having an editor I could trivially extend was key; M-x eval-region (I have it bound to a shortcut) dramatically lowers the barrier to altering functionality.
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#.
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.
IDEs can be great for writing code for particular platforms — I don't think there are many people writing Objective-C or C# in vim — but it's hard to imagine "ditching" a general-purpose text editor for a platform-specific IDE.
> 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'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.
I was a hardcore emacs user for over ten years but the extra features I get with a really good IDE like IntelliJ are worth the switch, IMO. Now I only use Emacs for quick & dirty edits.
There are environments which require a lot of tooling and automation in order to be productive. Integrated platforms like Android, iOS, or Visual Studio come to mind. These require so many configuration files to be kept up to date, build tools to be run in just the right order, and projects to be organized in special ways, that they are all but impossible to work with outside of the official IDE.
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 was a Vim user for 5 years, then an Emacs user for about 3, and then I purchased PyCharm two weeks ago.
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.
Nice, I looooove old school vi. O'Reilly's book on vi: Mastering the vi editor: 6th edition is my bible. I wish there were other sources of information and tips for vi. I really want to know what sort of workflows other people have.
I prefer using IDEs to navigate larger projects, and you get better code completion (I use Visual Studio for C and PHPStorm for PHP). I just have a hotkey to open up Vim at the current line/file, - I prefer Vim for heavy text editing and heavy reformatting.
One of the reasons I adore Komodo IDE (apart from it's excellent Python and Javascript APIs, and the fact that it's XUL based so building plugins is just like building them for Firefox) is the excellent Vim-mode it has built in. It's super extensive, one of the best emulations I've ever used.
I used Eclipsed(ADT) and now using Android Studio. Eclipse has the decent vim plugin too. It can detect your vimrc and you can use your key-bindings. Only a while ago, Ideavim has this features where you can load the config with ~/.ideavimrc . Overall, IntelliJ is nicer IDE than ADT
In Vim, a single badly-written plugin can make the entire editor feel sluggish. I'd recommend disabling your plugins one-by-one, until you find the culprit.
Yes, this is quite common. Come to #vim on freenode and we'll help you troubleshoot it. There's a large and welcoming community waiting for you over there.
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.
I'm curious how this isn't true in pretty much all environments. I guess I can understand how it might be heightened in vim. I can't think of anything that would prevent it elsewhere though. (There is also the odd incentive to have all plugins well written if the affect is pronounced.)
There's no normal workload under which Vim should ever slow down noticeably. I routinely have long-lived Vim instances with hundreds of open buffers, and some of the files can be quite healthily sized (tens of thousands of lines). It should even be fine for "pathological" cases (multi-megabyte log files, files with stupidly long lines etc).
I've been wondering lately if it has something to do with Airline. I'm using its visible buffer display and when doing C-movement s between buffers it feels so terribly laggy (on a top of the line MB Pro).
When switching via ctrlp everything is instantaneous, but that requires more commands than just C-k or C-j.
Early in my career I did a self-study of the entire vim user manual. My time has been repaid over and over, every single day, ever since.
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?
Try switching to a different terminal app. I get excellent performance running vim and my entire dev environment in tmux. I also find that the performance is pretty consistent whether I use chrome-ssh, cygwin, gnome-terminal or konsole. Honestly, I'd be surprised if any modern GUI toolkit could compete with a curses app in terms of display performance.
I've been using MacVim for close to 3 years now w/o any slowness, CtrlP (plugin) sometimes gets buggy with large projects but aside from that buffer navigation is always good, but then again I'm running on SSD and maxed out ram on my mbp.
I am not an Emacs user so I can't answer your question there, but I thought you might want to know that I experienced the same issues with MacVim and speed. However, Vim from the terminal works a lot faster for me. Using it from the terminal also removes a lot of your crutches, and forces you to do things the Vim way rather than the GUI way.
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.