Most of these vim emulators are open source, so there's always the chance to just fix it and do a pull request. The main two vim emulators that I am using are:
- XVim for XCode
- Evil for Emacs
And both do a really good job. Evil beats XVim hands down, but XVim is a lot better than the others I tried: IdeaVim (for Intellij), Vrapper (Vim for Eclipse), and Vintage (Vim for Sublime). Out of these, vintage is by far the worst. I think it does more harm than good because the missing and wrongly implemented keys confuse me so much that I get worse at vimming. IdeaVim lacked a lot of the keys that I use regularly important (vi", va", vit, vat, etc), and Vrapper was kinda good but I think I couldn't map jj to <ESC>, but it's been some time since I had to use Eclipse.
I tried to fix IdeaVim, but I browsed the source for some time and couldn't really figure out what to do. However, I also enhanced my local XVim and Evil setups a bit by extending the code and it was a lot easier than with IdeaVim.
I've said this before, but with all these implementations, somebody should have written a "libVim" in lua, that can be embedded in almost any project, and can be hooked into the input stream, and then you'd just need to define a set of methods in your delegate textfield (or what it is) and the libVim will call these methods based on input (i.e. move cursor, insert text at position, change text at position, scroll up, scroll down). I don't think you'd need that many delegate methods since mostly it is writing to a text buffer.
I think it would be better for developers to allow their programs to launch external editors. That way users can pick whichever editor they like. All the developer has to do is create a temporary file, run a command to open it, and watch for changes.
(Thanks to vimperator, I am using vim to write this.)
Most IDEs let you set a hotkey to run the current file through an external program (I generally use Ctrl-Shift-V to open in Vim) as well as a setting to automatically detect and reload a file that's been changed outside the IDE. It's not perfect integration, but it works pretty well once you're used to the workflow.
That would not enable you to use editor features like autocompletion, context awareness, etc. Now, you could also implement them in the external editors, but then you'd be at step one again and re-implement an IDE in vim.
I did a bunch of work for XVim a while back. The owner is really friendly and very welcoming of contributions, so if anyone wants to pitch in you'll find it worthwhile. When I first looked at XVim the code was a little disorganised. It was possible to fix it up with some fairly massive refactorings, and they were all warmly welcomed.
Once I switched to AppCode I thought I'd do the same for IdeaVim, but the code base is such an unholy affront to the gods that I gave that idea up.
Unfortunately, much like the author, my conclusion was to empty out my vimrc and start using a minimal subset that is definitely supported on all platforms. It's a real bummer, but it's definitely better than not using killer vim + IDE combinations.
I think it is wrong to say a plugin is not bad, just because you could add the necessary features yourself. You could also write a better plugin, but "ain't nobody got time for dat"!
I looked at Xvim some time ago and decided not to use it because it seemed abandoned. But apparently they're working on another branch! Good, XCode really needs a vim plugin.
va" and vi" are now supported in IdeaVim, as well as other i/a commands for ",{,(,[,<.
However, tags (vit, vat) are not supported, which is disappointing.
Fwiw, if you find yourself wanting a Vim plugin for just about any piece of software but don't know if it exists or not, just assume it does and google it.
I knew of eclim, which was to much hassle set up for me. Didn't have to use eclipse too much in the last years, but have to come back to it now. This was perfect timing.
This isn't a problem with vi(m) but with application implementing vi keyboard navigation. Neither vi nor emacs are just their navigation keys and I have a similar problem with anything that is like emacs in that there's always a shortcut missing.
Using Vim mode in other editors is like replacing all your silverware with only spoons. It's much nicer, shinier silverware, and everything's going great at first, until I subconsciously reach for a knife.
Emacs can have this issue too, often people wanna redesign keybindings, the community tries to explain that it's not worth it and won't catch.
Does readline defaults to emacs keybindings ? It surely benefits to Emacs, but the same can be said for Vim since he reuses a regexp syntax found in sed/grep, and even apply it on navigation
`d$` : delete until EOL (aka $).
^ for BOL ..
The composability of vim commands is a beautiful thing.
I remarked to a friend a couple months ago--right when I started to feel about the same way as the author of this article--that I love vim.
As I said these words, I realized that the truth in them is sort of startling. I love vim.
No, it's not like loving a person, but it's at least as strong an emotional connection as loving my favorite coffee mug or loving a particularly thoughtful gift from a friend.
As an aside, I often find vim verbs and commands sprinkled throughout things I write in other text editors. :wq
The worst thing for me is editing an Excel sheet. Every time I have finished typing something in a cell, I hit ESC, which results in clearing what I have just written...
I've always wondered how difficult it would be to extract the vim "engine" into a library that could easily be reused by other programs. I can only assume the answer is "very difficult".
Another idea would be some kind of VimSpec that emulators could be run against to see how well they cover the whole range of vim actions. Again, probably not very feasible.
You would be correct, I have seriously looked into doing this type of thing and/or modifying the Vim codebase. My conclusion after a few hours is that the Vim codebase is a horrific unsalvageable mess of nested ifdef's. IMHO reimplementing a "vim engine" from scratch will be orders of magnitude easier.
If you swap around the pedals of your car, I suspect you will have similar problems.
Another way is to swap back and forth, this will get you used to a new editor with less frustrations. But cold turkey is faster :)
Vim has ruined me as well. Nearly every other editor that has a vi mode really just has a vi mode, not vim.
This means that you cannot use 3 letter commands, but the 3 letter commands really are the most powerful. I cannot count the times that I have used ct( or ci", now after adding the surround plugin it becomes even easier with cs'"
Recently I was studying Programming Languages Theory with Racket (using this book - http://cs.brown.edu/courses/cs173/2012/book/) and I didn't like DrRacket. So I decided to use Racket with Vim, but the only way could do it was through GNU Screen and Slime plugin for Vim. It works, but it takes several seconds for expressions to travel from Vim to GNU Screen and it is quite inconvenient. Furthermore, I don't have invocation history in the REPL, so if I mistype function name, I'd have to type it all over again. Does anyone know of a better option for Racket with Vim? How do you use interpreted languages with Vim?
I tried using slimv as well some time ago but I never managed to get it working properly. I don't remember exactly what happened but I believe there were some bugs (like the lag you mention) and I couldn't figure out how to properly transfer just the piece of code I wanted to the repl. Plus I didn't want most of the plugins that slimv added (paredit for instance).
I use emacs with evil-mode (very good vim emulation) to program in Racket. The advantage of emacs is that it has paredit, geiser, and other useful plugins.
On the other hand VsVim for Visual Studio (https://github.com/jaredpar/VsVim/) is pretty good done and have many of the full Vim functionalities. I use it on daily basis and it feels almost as full Vim.
It lacks in support for plugins and many fancy settings but provides all the movements and register operations I use regularly in full Vim.
What is important it is fully open sourced and its maintainer makes pretty good job by implementing most of issues and accepting many pull requests. It is still updated and getting constantly better.
Many thanks to Jared Parsons for developing this plugin.
It's pretty excellent, but it has the same issue as any other vim-emulator. It's missing some keybindings that break my concentration. In VsVim's case specifically "cit"
For me, it was the other way around: I started as a vim user, but, once I started using Emacs, I could never look back. Proof General (http://proofgeneral.inf.ed.ac.uk/) is, put it simply, the best environment for certified software development with theorem provers. And, even when using more mundane languages like Haskell, having the REPL (ghci) running within the text editor if very useful when one is lost in type land.
My situation is the opposite. I spent 2 years with vim and switched to emacs. I used evil mode with emacs for about six months and then decided to go back to emacs bindings*. I use key chord mode and ace jump mode to quickly jump around. I find that workflow better and even easier on the wrists/fingers. Ultimately, whichever editor I use I end up getting hand pain on different fingers so I will sometimes toggle back and forth to balance it out.
Though I'm a long-time vim user, I've never even used cf" nor do I know what it means. However, I find most vi emulators work very well with the standard movement, yanking and inserting commands, and some basic visual modes.
I used ViEmu quite successfully a few years ago when I was doing C#, and I use vi mode on bash every day without many problems. If you keep it simple, you should be able to work across emulators pretty well.
ViEmu does support cf" (I would know, since I wrote it). It means "change up to and including the next double quote", which is indeed classic vi, and supported by any non-trivial vi/vim emulator. I would guess the author of the author of the article meant ci" (change the text inside double quotes), which is vim-specific rather than vi (even a recent vim version, not an old one). ViEmu also supports that, but I'd guess many other emulators won't.
Indeed supporting a large part of the vim commands most people use is no walk in the park. I started writing ViEmu in 2005 and I'm far from running out of oft-demanded commands and motions to implement.
The thing with Vim is that even though you can use it like a regular text editor, it isn't too good at that. But when you grok the Vim philosophy, enter one command, verb + noun, then do your edit and press esc, you'll feel like flying.
I think cf" is pretty standard. I think it is even a original vi command and not a vim extension. Change the text from the cursor position up to the first instance of the " char.
I normally use ct" which is pretty much the same but excludes the character which I find is normally more useful - if I'm changing something in quotes, then ct" makes more sense. ci" is the best one of those though (change inside ")
I also have the same problem as the op, I can't use vim plugins.
In that case, a couple of extensions of that which I use constantly:
cf" is change find "
But, since this is a grammar, there are other things than c we can use like d (delete find ") or y (yank find "). More than this we can swap out f. Instead of f, try i, which I think of as "inside".
So ci" deletes the text inside quotes and leaves you in insert mode. ci) deletes the text inside parentheses and leaves you in insert mode.
For example
foobar[somekeyvar] = "wooyay"
move to somekeyvar and ci] then type "anotherkey"
foobar[anotherkey] = "wooyay"
Oh I know that feeling, even when I learn a faster command, it only takes a day once I forget about using it. It is really difficult adding unknown commands to the list of muscle memory commands. I recently switched to caps-lock+G for escape (from jj) and that was a tough ride because my muscle memory would always hit jj.
I also feared I'd have a problem switching between vi(m) and other editors, but if you use both regularly, It's not a problem at all, at least for me.
I'm heavily using Sublime Text for software development. Sublime has a "vintage" vi mode which I don't use, just to train my muscle memory on modeless editors.
It's the same with keyboard layouts. I've been using german keyboards all my life and just decided to switch to us layout a few years ago, because basically the keyboard layout had a huge influence on programming languages, stuff like []{}/<> is way easier to type on us layout.
I feared i will never be able to use a german keyboard again after switching layouts, but this is not the case. I can now use both layouts blind. The only problem are the () parentheses which are offset by one key on the german keyboard, i'll always press the wrong key for them.
Ditto. Also switching between US for coding and my local layout and I think it's definitely worth it due to the ease of typing the slashes and brackets when coding.
A little anecdote from a project I worked on in the mid-90s (hence terms like "4GL".) The project had a lot of back-end programming (C and PL/SQL) that we mostly wrote in Vi, but the front end UI was this weird 4GL thing which I can't remember the name of.
One particular quirk of this 4GL was that pressing the escape key while in the editor would close the editor, do not save, do not prompt, do not pass go and collect $200. Very bad feature, especially when switching between editing in this and in Vi a dozen times a day.
In the end, everybody on the team had a bottle cap on their desk that they could put over the escape key when firing up the 4GL editor to stop accidentally hitting the damn key out of sheer muscle memory all the time.
After I learned vim, I got very frustrated going back and forth between vim and Mac apps (Mail, MS/Word, etc) because I had to switch between the vim and Mac style of keyboard-based cursor movements/selection patterns. So I sat down for a few hours and figured out how to exactly replicate all Mac cursor/selection shortcuts in vim.
Fortunately they don't really conflict with too many existing vim patterns, and it's pretty nice to be able to use the cursor/select patterns across vim and all Mac apps.
A lot of Vimmers have this exact problem. Vim has thousands of features, but each person ends up using / loving a couple dozen. The problem is, it isn't the SAME couple dozen so for an emulator to make any significant subset of Vimmers happy requires implementing thousands of features.
This is why all attempts to clone Vim end up failing, and why even amazing implementations (like Evil) fall short when that ONE muscle memory you depend on is missing.
Personally, this is why I limit my usage with vim with the core vim(to me it means vim-as-out-of-package-or-gvim-package), my customimzed .vimrc, and highlighting plugin.
The original vim alone is more than enough to satisfy my needs, and it's compatible with virtually every machine that I'll be using after all.
I can venture on plugins for more convenience, but I already have an ample satisfaction and I would rather keep it that way.
If you use Firefox, I recommend the It's All Text! plugin, which opens $EDITOR in a new window and seamlessly transfers its contents into the textfield you care about.
I think a Chrome version is in the works, but there's nothing releasable yet.
One of them is that vim is actually closer to a windows/mac style editor than emacs is. You can navigate with the arrow keys, you just need keep track of being in insert mode or not. The things that are different are sufficiently different that you won't cross them up. Back in the emacs days I was always typing ^X^S into word or typing ^S in emacs when I want to save.
I've found I switch fairly easily between browser-style editing (like here) and vim. Sometimes I forget, and have a few moments of perplexity, and then I'm OK. Maybe it's different for other programming editors (as opposed to browser editing).
BTW: one thing that helps is adding standard browser key-strokes to vim, so if I forget, it doesn't matter.
I never considered using vim because the navigation is based on a query layout, which I don't use. It didn't seem worth the effort to try and re-bind the keys to make more sense.
With emacs, the key bindings sort of make sense (f-orward, b-ack) (n-ext p-revious) for the right-left-down-up. Not sure why v is for page down/up, but it seems to have stuck.
I use Colemak and vim. I used to rebind the keys but it's not worth it since you have to redo it for every emulator (and some of them don't support remapping).
Since vim is mnemonic rather than ergonomic everything works great in standard Colemak - except hjkl.
I learned Vim on qwerty, then switched to Dvorak and re-learned the positions and I'm pretty fast again. Using it with qwerty is like being on drugs, though.
At least with VIM the standard commands are good enough to make one productive on any VIM installation.
With emacs, you have to do so much customization before it becomes useful that you find yourself completely lost when using another installation. Try helping a friend only to find out all your commands do not work...
> you find yourself completely lost when using another installation.
That can also be true for the workstation.
Example: I remapped my caps-lock key to ctrl. Swapped the top row around so the numbers and and symbols are reversed. Stuff like that.
Not even getting into customizing desktops: I use Enlightenment, the other devops guy uses what looks like a bastardized Window Maker and we'll never be at home with each other's computer.
Agree almost 100%. I do use vim mode for bash and it works great because lateral motion is most of what I'm doing there.
But Sublime's vintage mode actually was the breaking point for me, and made me go whole hog back to vim. Close enough to cause problems when it fails, like faux amis in a foreign language.
I have found Evil to be the best emulator that I have tried. But even then, I wonder, why try to emulate Vim? Why not just use Vim? And Vim is more than they keys. It's the whole ecosystem of plugins which come together to be the Vim way. There really is no replacement.
I'm a 15+ year vi user, and I can't stand vim. Everything about it is clunky and cludgy and nothing ever quite works nicely. I really want more features than vi has, but I can't live without vi input. So vi-mode plugins for various editors/IDEs are really my only option.
All the extra stuff that makes vim more than just a vi clone. Everything from built in stuff like the auto-completion to plugins like syntastic. Everything technically works, but never nicely and I always end up frustrated with the warts and just go back to plain vi. I should give emacs a shot, I've heard evil is supposed to be a better vi than vim.
Other editors/IDEs you are using with vi-mode plugins also have extra stuff that make them more than just a vi clone, from built in stuff like auto-completion to syntax checking plugins. etc.
Of course, I want those things, that's the whole reason for trying to switch from vi. I just want those things to actually work smoothly and together, rather than being a mess of plugins that sorta work sometimes but have lots of ugly warts and don't play nicely together,
I used vim on windows, but only started to like it after I installed ubuntu.
I also installed JOE, which has a word-star emulator, a pico emulator and an emacs emulator.... but no vi emulator.
Does that mean JOE has a 'vile' hatred of vi?
- XVim for XCode
- Evil for Emacs
And both do a really good job. Evil beats XVim hands down, but XVim is a lot better than the others I tried: IdeaVim (for Intellij), Vrapper (Vim for Eclipse), and Vintage (Vim for Sublime). Out of these, vintage is by far the worst. I think it does more harm than good because the missing and wrongly implemented keys confuse me so much that I get worse at vimming. IdeaVim lacked a lot of the keys that I use regularly important (vi", va", vit, vat, etc), and Vrapper was kinda good but I think I couldn't map jj to <ESC>, but it's been some time since I had to use Eclipse.
I tried to fix IdeaVim, but I browsed the source for some time and couldn't really figure out what to do. However, I also enhanced my local XVim and Evil setups a bit by extending the code and it was a lot easier than with IdeaVim.
I've said this before, but with all these implementations, somebody should have written a "libVim" in lua, that can be embedded in almost any project, and can be hooked into the input stream, and then you'd just need to define a set of methods in your delegate textfield (or what it is) and the libVim will call these methods based on input (i.e. move cursor, insert text at position, change text at position, scroll up, scroll down). I don't think you'd need that many delegate methods since mostly it is writing to a text buffer.