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.
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.
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.
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"
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.
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 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.
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.
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.
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.
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'"
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.
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.
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.
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"
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.
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 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.
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.
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.
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.
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...
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.
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 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?
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.
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.
89 comments
[ 4.9 ms ] story [ 134 ms ] threadI 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.
I also have the same problem as the op, I can't use vim plugins.
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
I use this constantly while programming.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.
Do yourself a favor and go figure out what's the difference between: cf" cF" ct" ci" ca"
Note: you can substitute c for any "verb" (d, y, ~, etc) and " for many delimeters.
- 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.)
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 would recommend Vintageous[1] which has implemented far more bindings. Although annoyingly, it does not have :w, which I use quite often.
[1] https://github.com/guillermooo/Vintageous
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.
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 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.
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.
Anyway, Vim has far more useful ways to move around than char-by-char. If you are curious, read `:help motion.txt`: http://vimdoc.sourceforge.net/htmldoc/motion.html#motion.txt
Since vim is mnemonic rather than ergonomic everything works great in standard Colemak - except hjkl.
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
The composability of vim commands is a beautiful thing. Cute little finger DSLWith 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...
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.
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
https://github.com/apinstein/dotfiles/blob/master/vimrc#L57
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.
BTW: one thing that helps is adding standard browser key-strokes to vim, so if I forget, it doesn't matter.
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.
I wrote this in vim, and copied here.
I think a Chrome version is in the works, but there's nothing releasable yet.
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.