From Vim to Emacs(juanjoalvarez.net)
juanjoalvarez.net
From Vim to Emacs
http://juanjoalvarez.net/es/detail/2014/sep/19/vim-emacsevil-chaotic-migration-guide/
122 comments
Bravo man, I tried to make the switch from vim to emacs evil and failed horribly. I would eventually throw emacs into a state where it wasn't in any of the evil modes, then bash my keyboard with C-X C-C. Is it possible to use emacs+evil without knowing emacs inside and out?
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 :)
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 would eventually throw emacs into a state where
>> it wasn't in any of the evil modes, then
>> bash my keyboard with C-X C-C.
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.
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.
I think the main problem is that in vim everything works like a buffer. When I browse files or any sort of search results, I can use the standard vim key bindings to navigate through or even dismiss the window.
With emacs, it seems like I have to learn the system to even use some plugins like projectile effectively.
With emacs, it seems like I have to learn the system to even use some plugins like projectile effectively.
Next time this happens try running evil-emacs-state. (Its bound to C-z ...I think that is the default binding that the evil install setup)
EDIT: just realized I posted this without saying why to do this. This command will put you into evil-mode even if the major mode doesn't start off in it for some reason. I use it all the time to navigate and search the output from package-list-packages for example.
It is possible to use Emacs + evil without knowing Emacs inside-out, but you do need some basic Emacs knowledge. If you had to do C-x C-c when entering a non-evil mode, you did not have that basic knowledge :-)
The least you should do is the tutorial that's presented on the startup screen or "M-x help-with-tutorial".
The least you should do is the tutorial that's presented on the startup screen or "M-x help-with-tutorial".
I always have a hard time figuring out why people would switch from one tool to another just to start configuring the other to behave like the original tool. Can someone name some reasons to switch from vim to a vim-like configured Emacs?
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?
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?
> Can someone name some reasons to switch from vim to a vim-like configured Emacs?
You're attached to modal editing but you want some of the Emacs plugins and a less terrible scripting language.
You're attached to modal editing but you want some of the Emacs plugins and a less terrible scripting language.
[deleted]
Emacs isn't superior to Vim in every possible way. I personally find Vim's modal editing hard to let go of. On the other hand, vimscript is an atrocity compared to Elisp. Vimmers have certainly managed to make some amazing extensions to the editor despite that fact, but no tool is perfect; the whole point of an extension layer is to make the tool work the way you want. The defaults aren't necessarily what everyone likes (or ought to like).
This may change with Neovim, though, since add-ons will, as far as I understand, exist separately and do IPC through JSON.
But you can get Vim's modal editing with Emacs'evil-mode.
Emacs is easier to customize. I used vim for 10 years before switching last year to emacs + evil. After a month I felt more comfortable in elisp than I ever was in vimscript. If you use terminals within emacs you can navigate and search through all the text as if it were in a vim buffer, imo a step above readline's vim mode. If you are comfortable with vim modal editing you must try emacs with evil, you get much bang for your "buck". I would also argue that even though you are using vim bindings with evil doing so is actually how emacs users would do it. I say that because the emacs way seems to be to customize it until you are comfortable.
Sounds like a very good argument. Customization would be the Emacs way. That at least sounds like the Editor Operating System association to Emacs.
I was a vim user for years. I accepted a challenge from the programmer who sat next to me (an emacs user): we'd swap editors for a week. Every time either of us swore or complained about the editor, we'd pay the other a dollar.
That was 2011. I've been an emacs user ever since.
That was 2011. I've been an emacs user ever since.
What about the other guy?
Good question! He switched to vim due to RSI I believe.
Conclusion: neither is better. I think.
Conclusion: neither is better. I think.
And you switched to emacs due to RMS ;)
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.
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.
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.
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.
> it was the best career decision I've ever made
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 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'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.
What are the first-class IDE-style features you want?
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.
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.
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'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#.
> Are there any other former vi/emacs users
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.
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.
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'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.
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.
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 use the vim plugin ("IdeaVim") in JetBrains PHPStorm & PyCharm.
I use vim for nearly everything, but will jump into an IDE when in a complex environment that lends itself to using an IDE (Android, C#, etc).
Old (old) school vi user here.
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.
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.
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 haven't read it myself, but Practical Vim is quite highly regarded:
http://www.amazon.com/Practical-Vim-Thought-Pragmatic-Progra...
A whole book of tips
http://www.amazon.com/Practical-Vim-Thought-Pragmatic-Progra...
A whole book of tips
That sounds like a good book for a vim user. I wonder how much of it would apply to vi, however.
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.
Are there any other former vi/emacs users (like, hardcore - I used to browse the web in emacs) who ditched it for an IDE?
Whenever I have to use Visual Studio, the VsVim extension gives me the best of both worlds.
Whenever I have to use Visual Studio, the VsVim extension gives me the best of both worlds.
I think the main thing is some developers never use keyboard shortcuts until they are forced to with vim.
I only started using intellij because it was the first IDE I'd ever used that had a decent vim keybindings plugin.
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.
[1] https://github.com/dahu/bisectly
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.
[1] https://github.com/dahu/bisectly
Another way to find the culprit is using vim' built-in profiler:
run :profile start filename, then :profile func * Then do the slow thing, and close vim. This will write your profile data to filename.
run :profile start filename, then :profile func * Then do the slow thing, and close vim. This will write your profile data to filename.
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.)
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.
Try running it with `mvim -u NONE <filename>`.
That disables all initializations from your .vimrc, plugins, etc. so you can see how fast "vanilla" vim is.
That disables all initializations from your .vimrc, plugins, etc. so you can see how fast "vanilla" vim is.
There is VimR, Vico and a plethora of other editors that support the VIM paradigm to an extent. You should be browsing around.
Try using terminal's vim. Works better for me, I rarely use MacVim.
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?
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'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 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 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
Try terminal Vim. I don't use MacVim and have very few issues with sluggishness.
I started with terminal Vim, began having issues with redraws, and made the switch. I find that MacVim is faster and more stable.
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.
MacVim is faster, except when it's not? :P
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.
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.
I use MacVim in the Terminal as well as a GUI.
Try putting `set lazyredraw` in your .vimrc
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.
When switching via ctrlp everything is instantaneous, but that requires more commands than just C-k or C-j.
Isn't it possible a good number of people install addons that cause noticeable performance hits?
Syntax based folding can slow it down a lot, especially with Ruby code.
"With Vim I had defined a keybinding that selected the last pasted text. It was useful when you wanted to reformat or indent text that you've pasted from somewhere. At the moment I've been unable to reproduce this in Emacs."
- 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.
- 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)))
No need for text properties, just make "yank-last-start" and "yank-last-end" markers instead of simple ints (https://www.gnu.org/software/emacs/manual/html_node/elisp/Ma...) - they will be moved automatically with every edit.
Oh, nice, I suspected there was a better way :-)
As someone who has always used vim, what are the benefits of this system over a standard vim installation?
You get a computing environment which "breathes" Lisp[1] and is itself mostly built up from a fully hackable Lisp codebase.
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.
[1] http://en.wikipedia.org/wiki/Emacs_Lisp
[2] https://github.com/bbatsov/prelude
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.
[1] http://en.wikipedia.org/wiki/Emacs_Lisp
[2] https://github.com/bbatsov/prelude
I disagree re: forking it, I think there's a lot of stuff that continues to be a bit of a pain to manage, but it's a good first start.
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.
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.
You get access to things like org mode and magit and deep REPL integration and an integrated package manager. You get the ability to configure absolutely everything in elisp. Many experienced Emacsers routinely write small snippets of elisp to automate some task. This goes well beyond adding a key bindings here and there, or the odd macro, and is really amazingly powerful.
Can't you do the same thing with vimscript (or python, if you're using +python builds)?
No. This has been discussed ad nauseam already. Vimscript offers a limited API to some functionality of Vim. Emacs is written in Elisp, and thus, everything is accessible and changeable in Elisp. What is more, Emacs and Elisp were designed from the ground up with malleability in mind.
I love seeing this on the front page. I've been a Vim user for a few years and feel like there isn't a ton of help out there for switching to emacs + evil.
Here's my migration guide from early September, if you're looking for more resources:
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:
http://bling.github.io/
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:
http://bling.github.io/
I should probably write a blog or something about this since I've spent quite of time getting Emacs to behaving like Vim with Evil. I went the Prelude route, because it included a lot of cool things out of the box and I felt like I could just customize it a bit. My main goal was to get an Emacs environment that behaved like Vim for working through the SICP using the Geiser plugin. There's surprisingly little that has to be customized to get a well-behaved Emacs.
Here is my prelude customizations:
https://github.com/humana/dotfiles/blob/master/emacs/persona...
Here is my prelude customizations:
https://github.com/humana/dotfiles/blob/master/emacs/persona...
The "problem" with vi is that you'll outgrow it very fast. People tend to work around this by installing a dozen of plugins but I think you should use Emacs for that.
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.
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.
Huh? vi does not have any plugins; only vim. vi is even more bare-bones than vim, lacking a lot of features (macro recording and text objects being the ones I miss). It is extremely common to find vi pre-installed on countless servers, however, making it extremely convenient if you're an expert with it.
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.
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.
This bothers me. People should just call it vim when they mean vim. I suspect most people here haven't actually touched Joy's vi or its closest derivative, nvi.
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.
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.
It probably comes from the fact that most people alias vi to vim. And from the fact that when you type vi, you're probably not getting vi, but vim in full compatibility mode.
These actions make the two interchangeable in people's minds.
These actions make the two interchangeable in people's minds.
[deleted]
If you want to use emacs as if it was vim why change?
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 :)
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 :)
"If you want to use emacs as if it was vim why change?"
-- 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.
-- 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.
The only thing I really like in vim is the modal editing. Evil replicates all that stuff really well in my opinion.
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.
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.
I thought this was the case too, but YouCompleteMe is really terrific for Vim! I wish emacs had something similar.
Have you tried company-mode?
http://company-mode.github.io
http://company-mode.github.io
This looks great! I can use Emacs again!! Thanks!
Haven't actually tried it, but I've come across https://github.com/abingham/emacs-ycmd before and it looks decent? I also use autocomplete-mode which has a bunch of hooks for pretty much every language under the sun. I have it set up with jedi for python and clang for C/C++/Obj-C.
[deleted]
Having used EMACS all the way back to the original Stanford SAIL machines (with a physical META key on their custom keyboards) I still don't want to use it.
I'm vim guy and I started to watch http://emacsrocks.com/
There are another similar sites?
There are another similar sites?
I don't know of any. However the Reddit community http://reddit.com/r/emacs is pretty good for linking to any videos / tutorials / interesting new packages that come up.
I used Emacs for 4 years in school and was pretty comfortable with it. Couldn't use it when I was logged on to some server at my first job. Picked up vim .. use vimperator on firefox. Been using it for over a decade now.
I'm a vim (loser[1]) and terminal (power) user for 7+ years.
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...
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...
It's not quite the same but since Emacs is primarily an OS it has window managements build in, so by running it fullscreen and making a bunch of horizontal and vertical splits you get pretty close to i3[1] as well.
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...
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...
But Vim has window management built in too, with splits, tabs, buffers, etc.
vim is already too slow (i typically code edit with elvis which is good but not for huge text data files). evil's lagginness is utterly maddenning. and emacs isn't typically installed everywhere. i'm a multi terminal user who typically works remotely via ssh, remote usually being over a gigabit connection. I can probably burst 120+ wpm and yeah watching other people code is typically very painful. And I don't use plugins, thats what a posix shell is for.
If we're being pedantic, Vim isn't installed everywhere either. Vi is, of course, but if you're evangelizing the benefits of the posix shell over vim-specific plugins I can only assume you didn't mean to :%s/vim/vi/ before hitting reply ;-).
I made a similar switch to SublimeText, at least for programming tasks (non-programming tasks I still use vim since it works with just a terminal). Vintageous has a much better vim emulation than Vintage (the default vim plugin to ST), and ST has lots of interesting plugins. And I can use both modal and non-modal shortcuts (I use, for example, Ctrl+S to save rather than Ex-mode's :w since I find it less disruptive for my workflow).
I firmly went the other way a few years back, and haven't regretted it. Looking at this how-to, I have no real urge to back, though it is a good writeup.
> I don't miss any text command, operator, motion or work flow from Vim. Marks, paragraph reformatting, visual mode, visual block, macros, registers, text objects, splits (vertical, horizontal, :normal, folding, etc)... it has almost everything.
Tried for 10 minutes and found out it has not g-/g+. (still awesome)
Tried for 10 minutes and found out it has not g-/g+. (still awesome)
"I'm totally addicted to modal text editing to the point that I feel crippled when I've to edit text in a non-modal editor...but if you can imagine somebody programming on an on screen keyboard on a tablet, you know how modal editor users feel about non modal edition."
And vice-versa.
And vice-versa.
By default, most themes look like shit on terminal Emacs (emacs -nw if you don't want the window to open).
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.
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.
You guys need to start doing some real work instead of playing with your editor all the time...
That's kind of a poor attitude to have on a forum about -hacking-. :P
An age old debate and both are great! I used Emacs for a decade plus and on a whim spent a vacation re-programming my fingers for Vim and stuck with it as it felt slightly faster, not sure it really makes a difference :-)
[deleted]
If anybody would ask me "should I learn emacs or vi?"
My answer is "lern vi!"
Impossible.
yo why is anyone reading this kind of shit
-_- seriously how much can we talk about vim and emacs
I think you're just trolling, but I'll respond as if you're sincere.
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.
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.
You know, I agree that I shouldn't care. That was a momentary sentiment.
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.
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.
I hear ya. I actually hate listening to pointless debates about vim vs emacs too – especially if it's among coworkers or some situation I can't just ignore.
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.