My biggest problem with Vim
haldean.org
haldean.org
I've found that if I completely break the expectation that I'll get anything even remotely "Vim-like" outside of Vim, I'm better able to deal.
...though I still wish I could make every editor I have to interact with a Vim window. :)
* select all: ctrl-a
* copy: ctrl-c
* spawn vim: ctrl-f ! vim enter (varies by desktop environment)
* paste contents into vim: :.!xsel -o
* edit text in vim
* copy contents from vim: :%!xsel -ib
* close vim: :q!
* paste contents into original window: ctrl-a ctrl-vAlso having <C-p> and <C-n> as up and down means that moving between search suggestions on sites is really easy, which is nice.
f 24 ^M - choose reply
f 6 ^M - enter text buffer
^i - open vim
*** write this message ***
:wq - message gets transplanted into text buffer
esc, esc - exit text buffer, exit insert mode
f 7 ^M - choose reply again
???
profit - vimperatorI'd replace your second step with 'gi'. Saves a char, and avoids scanning for numbers..
You can also easily configure vim so that simple 'y' and 'p' will operate using the system clipboard, which I do.
You don't have to spawn and close vim around each task either.
Of course vim has no way at all to reduce the amount of ctrl-a, ctrl-c, ctrl-f, ctrl-a, ctrl-v boilerplate you are doing in this example because that all occurs in some other program.
Very nice. I like xsel because it gives me more flexibility and uniformity (I can pipe it to/from whatever, and use it the same in the shell as in vim), but I'll probably wind up using the above for simple cases (especially if the xsel command I want isn't in my history for some reason).
I definitely agree that having a faster way to use the system clipboard is great, but I don't like cloberring the clipboard when I do deletions and whatnot in vim, so I have <Leader><Leader> (I use ; for leader, seems like most people use ,) mapped to "* which I find much easier(;;y is so much faster than "+y for me).
Tough project, but needs to be done.
Vim has support for scripting against Python and Ruby in addition to VimScript.
Better graphics? For what purpose? For displaying text?
Spoken like somebody who's never tried to parse C++.
vim has a fully configurable syntax highlighting system; its behavior is not hard-coded. So if you have a problem with how C++ is highlighted then you don't need to petition for the developers to patch or rewrite vim for you.
You can tweak the related configuration. And it's true that it's really not that hard to make your own new configuration to do this. Because you aren't compiling the code, you are only highlighting it according to your own tastes.
Given that vim is open source, I'm not sure why you think hard-coded syntax highlighting would be impossible for me to modify.
It appears that you are preoccupied with hard-coded construction of ASTs for some dialect of C++ inside your editor. I never suggested it could not be done. But, this is a different issue.
However, I really don't think many people need that when the facilities for configuring syntax highlighting are so good. The existing system has allowed vim to support a crazy number of languages and have fresh support for languages quite quickly after they start to be used.
If you like vim, and you want something SPECIFIC to be fixed about its C++ highlighting (not just a general complaint that you feel it is 'woefully limited' because it isn't based on hardcoded static analysis for C++) ... then don't waste time on doubt. Just try it. Make your own highlighting script and see if it works to a usable level. If it does not, then you know, and not just because of some a priori principle that syntax highlighting is useless unless it is based on an AST generated by your compiler toolchain or something.
If you really did have any practical reason to believe that the existing syntax highlighting facility was totally unsuitable for more than a handful of people... maybe it would be interesting to have some way of plugging in external modules of some kind to provide ASTs for specific languages. (Because I think the idea of making my text editor totally coupled to a specific hard-coded implementation of a parser for a particular language sucks really bad; but if you don't think that, then maybe you just want to buy a C++ IDE and be done with it)
... but, what about microformats (not the w3c-flavor) in other files. say: any in-place templating language (php), code blocks in markdown, etc.
that would be really great. it does not stop at syntax highlighting though. i'd really like my erlang mode in markdown code blocks :D.
and Lua, Perl Tcl and Racket.
There are multiple markdown syntax highlighting plugins, but none of them work most non-trivial markdown features (a paragraph indented by four spaces after a list item is a regular paragraph not a code block; extend the same analogy to multiple nested lists...).
I don't know how the syntax highlighting could be better since it is already fully scriptable and allows 256 colors, etc.
So what is it that needs to be done? All I get from this is that you think vim should have "better graphics like what Sublime 2 has". So I ask sincerely: what is the actual essential functionality required and why would it demand a 'new VI' rather than a patch or plugin?
If you can formulate what is needed more specifically then it's more likely that you can fix it yourself or at least have a chance of enlisting someone else to do it.
Also, it is written in Haskell.
For the record, the first commit to the Yi project was 8 years ago. This isn't some flash in the pan project.
If you cannot think of at least one language which is older and a better common denominator than Haskell (both at the binary level and at the interface presented to programmers)... I don't know what to say.
What actual reason do I have for switching from vim to yi? Just because it's written in Haskell and that obviously makes it better, or what?
For instance?
I'm honestly wondering how people do to use vim for their projects. Are they giving up on refactoring althogether, or they are doing them the slow-way, step by step. Same for intellisense, I find it's so convenient to have documentation and in-context pop-up right in the middle of my thoughts; it makes me doubt of the productivity advantages that vim-evangelist claims.
I really try hard to learn more, to tweak vim more, to tame it more, hoping to reach the top of that learning-curve and to see just how ignorant I was before. But I'm in doubt. Is it real, or is it just some cultural dogma that vim is the ultimate tool?
I did try a few literate programming variants -- but it required a lot of discipline to keep the abstractions in the right place -- literate programming makes procedual/classical programming really efficient and easy -- but all that magic "transclusion" makes it easy to write something that is readable and structured in it's "natural" literate source form, but is pretty bad object oriented code.
I primarily do TTD style development, so it's very obvious where things break when I refactor something. I know a lot of Java devs rely on refactoring tools, but I never really had the need for my Ruby and JS work.
Regarding refactoring; I don't really miss it at all. For renaming, I simply use vim-ack and find where a rename would need to take place. In most cases (for the projects I work on) we're talking about the difference of maybe 30-45 seconds.
Intellisense is cool; there's no doubt about it and there's not really anything that comes close in Vim (omnicompletion really does pale in comparison). That said, the only type of projects that I've ever felt I really used Intellisense were sprawling Java applications. I've never missed it while working on JavaScript or Ruby projects (and, anecdotally, I've heard many C and Python developers also talk about not needing this feature).
Ultimately, Vim benefits me with overall productivity (for example, it takes Vim an order of magnitude less time to start up than Eclipse on my Macbook Pro--and then proceeds to lock up every few minutes while it does GC or whatever the hell else it does to just randomly stop from time-to-time). While I'm in the mode of writing and editing code, it's also significantly faster and easier on my hands and arms to be totally keyboard focused.
All that said, it's a really text-centric form of programming that is somewhat different from the hand-holding (not meant as derogatory; just a statement of fact) and all-in-one approach that an IDE can give you. There are some contexts (Java) that just aren't well suited to editing in Vim (but they're probably not suited for Sublime or TextMate either, honestly).
Exactly. I've recently been using omnicompletion with Go (gocode) and while it's neat, it is not essential as completion is when writing Java/C#/ActionScript. I believe it has to do with the former language's reliance on multiple-inheritance as opposed to Go's duck typing. With multiple-inheritance one seems "farther" away from atomic data structures; to understand the objects one must learn an entire tree of taxonomy.
Personally I find Go's approach refreshing; with one page of documentation one can "see" how an entire collection of types (structs) relate. Here's an example: http://golang.org/pkg/database/sql/
>Ultimately, Vim benefits me with overall productivity
...and it's not just coding where vim increases productivity. I can't count the number nights I've spent writing essays or final papers in college with nothing more than vim, ispell, and the book I'm reporting on. When editing text becomes reflexive it is so much easier to express oneself.
I've had very poor luck getting omnicompletion to work to my satisfaction, but one thing that works very well for me is opening buffers for several files related to what I'm working on and just using <C-n> / <C-p> for basic completion. I always have a bpython console open to test bits of code and make sure I'm calling functions correctly. The one thing that I miss is being able to complete a function name and have a small window pop up with its arguments and documentation. I've tried writing some simple plugins for this but have never managed more than a hack of a solution.
My system works incredibly well for me and I wouldn't use anything else, but many of my coworkers use totally different methods and I don't blame them.
http://stackoverflow.com/questions/5641001/clang-complete-fo...
It's not cultural dogma that vim is an ultimate tool, but that doesn't mean you have to learn it if you don't want to or don't understand the use cases. (Or you prefer emacs, which is equally capable). I felt the same way for years.
This is a fairly viable ecosystem on unix systems for C and C++ at least. You use whatever text editor you prefer, your chosen compiler and build system, gdb for debugging, and more recently clang for intellisense (though I do not know of a good standalone refactoring tool). For most text editors there are plugins to integrate the things that should be available in your text editor like debugging and autocompletion.
For your specific complaint of autocompletion, clang complete (https://github.com/Rip-Rip/clang_complete/) is excellent, but can be slow on large projects. Some other useful plugins are syntastic (https://github.com/scrooloose/syntastic/) for syntax checking of many file formats, tagbar (http://www.vim.org/scripts/script.php?script_id=3465) for convenient code navigation, and UltiSnips (http://www.vim.org/scripts/script.php?script_id=2715) for the best snippet plugin out there. The only thing I find I'm really lacking is good debugger integration (Pyclewn is ok, but not great: http://pyclewn.sourceforge.net/) and good refactoring tools. I've heard good things about eclim, but never tried it.
All of the command-line apps I depend on either use GNU readline (which has flawless emacs style editing) or can be hacked to do so with the rlwrap utility. Furthermore since many of the NeXTSTEP hackers were also emacs users, OSX text input widgets inherited very solid (although the kill ring is lacking) keyboard binding support which makes it possible for me to comfortably emacs-style edit in native OSX apps.
Sometimes though stupid rich text input boxes used by wikis can annoyingly rebind emacs keys, and then I fly into a fit of rage like the author described. Luckily there is 'It's all text!' under Firefox or 'Edit with Emacs' on Chrome that lets you use an external editor to edit the contents of any web text widget, which I use to do all my wiki editing.
Wait till RSI kicks in. Vim was a real relief when chording became intolerable (even with remaps like ctrl->caps).
The Kinesis took a few weeks to get used to, I sped up my progress by competing in typing races on typeracer.com until my speed got back up, and eventually surpassed my speed on a conventional keyboard. The square, curly, and angle bracket keys took a lot longer to get used to, and it was months before I got comfortable with them.
http://kizzx2.com/blog/wp-content/uploads/2012/06/layoutcont...
However, it seems like it's a common problem not to be able to specify your own behavior for GUI controls at a system level
I agree that a good OS should allow you to choose your editing keys (either vim or emacs style) and not allow applications to step on them. Unfortunately that's a feature that most users probably wouldn't care about.
If my hands weren't so full and I had any special level of expertise with GUI development, this is an itch I would find worth scratching - I don't imagine this could occur anywhere but linux and bsd, though.
I still have fit-of-rage moments when I try to use things that either (a) try to roll their own line editing or (b) use some inferior readline clone.
rlwrap is nice, but typically the shells I'm using have other functionality that I miss too much (tab-completion) if I use it. For instance, I've given up using rlwrap with the Scala repl for this reason.
I hear that. At some point Ubuntu screwed up and linked the MySQL client with libedit instead of readline, which has caused me much wailing and gnashing of teeth. Don't get me started on all the ways Ubuntu / Debian has fucked up the packaging of MySQL.
vim gives you ergonomic benefits? Sure, I can believe that. Allows you to manipulate text faster? Ok. But, at least in my reality, text manipulation is a rounding error when it comes to productivity. I simply do not buy the argument that using vim improves your code, or the speed at which you can write it.
Using notepad (on Windows) has 0 up-front cost. But you are going to be frequently frustrated, you are going to frequently produce files with errors in them that you have to fix, and you are going to be frequently doing things in a repetitive way. And then you are going to have to do things differently on another platform, etc.
Using a highly configurable, plugin-rich, live-programmable editor like vim or emacs does have some up-front costs to configure and learn to use. But almost certainly not as much as you think. They LOOK absolutely terrifying, but the reality isn't so bad. (I haven't found it bad, anyway - I certainly don't keep around refcards or consciously memorize things, although that might mean I'm not taking 100% advantage of the tools or maxing out my geek score.. those just aren't my use cases).
Feeling frustrated all the time breaks up your flow and just feels bad. And yes, if you are feeling frustrated with repetition, you probably ARE wasting real time... but it's up to you whether it matters. Some people have half the productivity of others and get by fine and get paid the same.
The underlying philosophy here is: it's a programmable computer, you should be able to have it your own way. vim and emacs are the fruits of text editing being a really mature problem domain for software.
But if your philosophy is rather: I don't want to take an extra week to learn a new tool... then you are not ready and might never be ready to leap to a really strong text editor.
vim and emacs have warts. but if you know them and need their power, it will not matter much to you that (say) scribes is so much simpler and prettier, because the absence of warts doesn't make up for the massive loss of functionality.
Each of these embodies about a lifetime of very poorly compensated work; there isn't anything else like them in the pipeline, so you might wait a lifetime for something with the same functionality and fewer warts. And the problem is that others will perceive warts in the new thing and it will be a religious war just like vim vs. emacs.
I wish Vim could read its configuration from a HTTP-URL passed in an environment-variable:
REMOTE_DOTVIM=https://foobar.com/dotvim
There are hacks around it, but they are nasty (pasting a script, aliasing stunts).
I realize the chances for actually getting this feature are rather slim. But gosh would it make my day...
curl http://url.to/vimrc | vim -u -
But yes, in essence that's what I'm doing right now, just instead of curl I rsync the entire dotvim and then run 'vim -u' (plus a few other vars).
It gets the job done (usually), but it's an extra-hoop that I wish I wouldn't have to take. More than once I've had the alias that I setup with the pastie fail for one reason or another, which then sets me back a couple minutes, torn between fixing it yet again or just moving on with plain vim.
You mentioned the notion of shared machines; I'm resisting the urge to go on a rant about the inherent "badness" of sharing a single login across multiple people in what is a multi-user environment. The whole point of a user account is to be able to set things up the way you want them.
That's the age-old discussion about to what degree one should sanction user-logins to production-hosts and whether permission/sudo-hell is preferable over the alternative.
It doesn't quite belong here so let's just assume the classic case of "bootstrap gone awry" where you're left with root, vanilla vim, and a semi-rational desire to have your fancy syntax-highlighting while you fix up that partition table. ;)
I think I would've solved this by (somewhat similar to sudo in some respects) setting VIM to point to your home (this might mess up ownership of some files, though) (see :help $VIM). You could set this in .bashrc (I think) - or your vimrc file that you can get from an url. It would require you to have access to your files, either way of course.
If the main use case is "just" root, maybe have something in roots .bashrc that sets up /home/root/<normal user name> and maps $HOME there? You'd have to be a bit careful setting it up to create that structure if it was missing, better to make sure all hosts have it by default... you'd still need to map your username for your root-session...
(If you can use sudo, then see sudo(1) and $SUDO_UID and $SUDO_USER -- you could have .bashrc map HOME to /home/${SUDO_USER}/.root for example?).
Sorry if this comment is unclear -- I'm not entirely sure what problem you're really trying to solve here.
I just tried it with http://dump.ninjaloot.se/hn.vim, and it seems to work.
This works to a degree but misses all the plugins, thus currently I'm using rsync - basically pasting a giant blob that turns 'vim' into an alias that first rsyncs and then runs 'vim -u'.
The point is that I have to remember pasting that blob, sometimes the blob fails, etc.
I'll be the first to admit that this is pretty much a Maserati-Problem. Still, keeps crossing my mind...
I think it's an interesting problem, indeed. I've been blessed enough to only have a few machines (<10) under my current care, and I've used the github variant mentioned above on all of them.
How many plugins are you using? Maybe you could make a vimrc.portable that contains the basic stuff that you need, but isn't the complete setup. I know I don't need all the 40-ish plugins I have in my full setup when I'm just doing sysadmin stuff.
And more generally this is an instance of bootstrap-dilemma: When are you most likely to ssh into a host directly? When something is wrong with that host, presumably with the automated bootstrap. :)
So I think the problem has broader scope than vim. If you want separate configs for anything (not just vim but your shell, etc.) then you will need some slightly clumsy indirection. One idea: the shared account has a script or alias for specifying which personality of config you want. './cfg moe' could set CFG=~/.cfg_moe, wget it from http://internalhost/moe if it doesn't already exist, and alias vim to vim -u "${CFG}/.vimrc". Is that a possibility?
If you can't have even a shared script then we are talking about pasting in a URL every time, in which case you can also paste in some awkward snippet...
to mount a dotfiles or .vim directory via sshfs...
to check out/cache your config locally (into .cfg_moe or something) and then run vim -u to pick it up;
or vim -c with something to source a remote vimrc file every time.
However, without knowing about your environment, I am skeptical that very many bootstrap failures will result in a condition where you have a functioning system with thousands of files already, can't scp anything in, but can ssh in. And in those rare conditions it seems to me less of a big deal not to have all the config, it just makes it important to be able to function without it every now and then.
History made marvelously easy. This alone sold me on the extension.
Vimperator still works on my somewhat age'd 14.0 FF.
Note that this are not vi(m) keybidnings, they are classic Unix keybindings that should work on any Unix application. (They even work in Plan 9!)
" remap Esc to jj in Insert mode: inoremap jj <ESC>
I've been using this for a while, much better.
That is not an ergo expert. An ergo expert would tell you to stop typing with your wrists bent and resting them on your desk or keyboard “wrist pad” or whatever nonsense. Your hands should hover over the keyboard. I have never, ever had wrist pain and I type _a lot_. I'm not an ergo expert, I just type with proper form as recommended in any credible health & safety or posture guide.
Remap Control to Caps Lock and there are no ergo issues at all.
I don't use emacs except once in a blue moon, but do use readline / emacs-style bash commandline editing. The ctrl-mapped features (and yes, I swap capslock/ctrl) are easy. The meta ones ... not so much.
Also, the escape key was in the place of the modern day tab key making switching modes much easier.
By building your workflow around Vim (or anything else) you can gain a lot but you also become a prisoner to it. I suppose it's about trading flexibility for power. Thus far it seems to have been net win.
It also seems that you can't see this from outside, which leads to people recommending their own tools for everyone else.
The reason is software tools evolve really fast. And you will always get somethings better than what was available in the past. And you will always have to move on. Why get so addicted and get into the editor religion?
If you look at the way people program in verbose languages these days, they heavily depend on a lot of goodies like auto complete and intellisense. The tooling area is always evolving with time. And not moving with the trend will keep you locked in ancient practices.
The way I see, Editor religion works very similar to version control religion. People really take tools too seriously. When I look at vi/emacs vs something else debate. To me it looks like git/mercurial vs svn etc debates. There is not reason to take that personally, they are just tools after all. I look at a version control system as something that keeps track of my change history. An editor as something that helps me be productive. Those things keep changing with time.
Don't take them so personally that you have to tear your hair out in frustration when they are not available. They are a means to achieve your goal. Using them is not your goal.
Read this for an overview of what makes vim vim:
http://stackoverflow.com/a/1220118
I wrote about some of my favorite commands here:
Simply thinking that the hotkeys are esoteric is missing the entire point of the command structure which is effectively a language for text manipulation. Google for "vim nouns verbs" for some great descriptions.
I'd say that vim makes you faster. It's like talking with your close friend vs talking with a stranger. You understand each other better and can speak very quickly. High bandwidth communication maybe?
Maybe its "working with you"
Just like I've learned to express ideas in various programming languages, I've learned to express ideas in Vim. Those ideas are within the domain of text manipulations. Even if I spent the same overall amount of time manipulating text (I don't) the process of getting from point A to point B is smoother and costs me less mental energy. That energy savings translates into better code.
One thing to note here is that, just as with any other notation, there is a learning curve. You must learn the essential complexities of the problem domain, as well as the accidental complexities of the notation. That learning requires deep understanding of fundamentals, memorization of idiosyncrasies, and practice, practice, practice. This is true in mathematics, spoken languages, written languages, programming languages, sheet music, and all the rest!
> Even if I spent the same overall amount of time manipulating text (I don't)
I'm just saying that faster code editing is a side effect of -- or the aggregate view of -- smoother thinking and faster thought expression.
I think the body of knowledge regarding vi(m) hotkeys would fall under this definition when considering the entire world. I mean no ill will by the description.
Two modes: command mode and insert mode
You type in insert mode. You do everything else in command mode. You'll end up doing most work in command mode (well, sort of).
Command mode is centred around verbs, modifiers and nouns (objects).
A typical verb is "d" for delete. Example noun are "w" for word, and "double" for line. So in command mode, "dw" deletes a word, "dd" (you see what I mean by double now) deletes a line.
Yank "y" copies a noun, paste "p" pastes it after the current position.
How do you copy a word? That's right: "yw". A line? That's right, "yy".
For how vim works, see eg:
http://yanpritzker.com/2011/12/16/learn-to-speak-vim-verbs-n...
For how you can become more effective with vim, or any similarly powerful editor, I recommend watching:
"7 Habits for Effective Text Editing 2.0" http://video.google.com/videoplay?docid=2538831956647446078
It's not about the esoteric hotkeys - it's about having a consistent framework and tool set.
When I first started with Linux in the mid 90s I didn't get vim at all. As most people I had a hard time closing the thing when I accidentally opened a file with it -- I seem to recall switching to another virtual terminal and fiddling around with "ps", "grep" and "kill" (I didn't know about pgrep/pkill at the time).
Now I cringe everything I have to use a web browser that doesn't support vimperator/pentadactyl -- and I'm not even much of a vim power user.
edit removed erroneous and confusing reference to "l", some spelling errors.
I'm pretty sure this is due to my expectations. I've never expected anything other than vim to have vim-like editor capabilities. Just having hjkl navigation is a major plus for me, and anything else is mostly gravy. Another thing I've found is that most of the plugins (at least the browser ones) are quite configurable, and if I'm not happy with or missing a keybinding, I'm free to modify or add it. I never liked gt and gT for tab switching, so I use zh and zl in vim and in my browsers, and AFAIK all of them (vimperator, pentadactyl, vimium, vim-chrome) allowed me to use them.
btw, an honorable mention should probably go to tmux, since it's copy buffers in vi-mode have pretty flawless vim-likeness.
If you simply want the breadth of experience without access to such a system, the 'nvi' package (available on most Linux systems) promises to be bug-for-bug compatible with BSD vi.
But when I'm coding, I'm in Vim mode. Moving between the two is much easier because I'm so used to it.
Almost everything is about mobility to me. I want to be able to sit down at any computer and accomplish my workflow the same way I do at any computer I own. Thus, the web and plain text are my friends. This was also the reason I started using Vim in the first place - I know it'll be on any linux box I ever use.
Pentadactyl doesn't support Firefox 15+ so I had to downgrade to a more stable channel with every major Firefox release. After I ended up in the stable release with no Firefox 15+ support in sight I began looking for alternatives and to my surprise Vimperator is still alive and kicking (3.5 got released six days ago)!
I don't get runtime errors anymore, it looks and performs much better (not sure if I should attribute the performance increase to newer Firefox) and has way better UX choices (like how minibuffer overlays the page instead of resizing it with every keypress which has a performance impact with heavy webpages)
I suggest every Pentadactyl user who doesn't need the better vim compatibility or extended configuration options to check Vimperator out, its still in development and certainly didn't get abandoned or superseded by Pentadactyl despite what people are suggesting.
[1] https://chrome.google.com/webstore/detail/dbepggeogbaibhgnhh...
As a full time dvorak typist I can tell you that it has definitely helped with my RSI (as has using vi). Dvorak is comfortable. It's hard to explain, but it feels like one's fingers are "rolling" over the home row when typing.
Second, who said having the all on the home row is better? Studies --nit Dvorak's own-- have shown marginal or no improvement compared to qwerty, ven for typists.
About the having keys on the home row, I certainly claim it is better, and you should try it for yourself. I will concede that it may not give a speed increase for a seasoned typist, I suspect that at a certain point when everything is in muscle memory it doesn't matter anymore. However, having to move your fingers less is simply less straining, so it will be more comfortable. This was not measured in those studies, so that's why I think they are not relevant.
It's a really cool keyboard. I wish Apple brings it's thumb+index finger twist [2] to do Ctrl-W to their laptop's touchpad. You can see the roots of their pinch to zoom gestures all in the keyboard, and it had much, much more. Apple acquired the company and it's IP in 2005.
[1] http://en.wikipedia.org/wiki/FingerWorks
[2] Actually, it might have been 4 fingers (minus pinky) twist. It's been a long while. I'm sure I'll remember how to do it once I have the keyboard in front of me. Just like vi keys.
This approach would be better because there will be a single effort rather than each editor writing its own vi/vim mode. Also when a new feature is added to the engine it would be available on all editors.
I've only used it lightly, but I've been pleased with vrapper so far:
http://vrapper.sourceforge.net/home/
It is also conveniently installable from the Eclipse marketplace.
cf" : change(c) forward(f) to double-quote(")
E.g:
- ci" (change inner double quote) will change (delete and put you in insert mode) the text between to double quotes.
- ca" (change _a_ double quote) will change the text and the surrounding double quotes.
There are text objects for quotes, brackets, sentences, blocks, etc. There are also plugins that create text objects such as arguments (to functions) in programming languages.
ct"
Changes Till "
I know it has zap-to-char but that works like cf" not ct". Of course that can be modified with a bit of elisp, but I wish it provided it out of the box.
Vim Quick reference: http://www.digilife.be/quickreferences/QRC/vi%20Quick%20Refe... [pdf]
ct"
c%
c/something
Change inside double quotes.
Or cit, change inside html tag. (not sure if this is in vanilla vim but I think so)
Replace " with any of these (,'{,[,< for other powerful commands.
Pentadactyl is perfect because it creates it's own verbs. Once you grok that a tab is it's own buffer it works as supplement to vim, not as replacement.
The rest is all zshell/vim.
imap <C-a> <Esc>^I
imap <C-e> <Esc>A
imap <C-k> <Esc>d$A
imap <C-y> <Esc>pA
Yes I am a heathen.
In all honesty, a lot of Vim users set up some of these same shortcuts for editing their commands since chording is really the only way to get to some of that functionality--and as long as you're going to use chords, why not use Emacs-style?
I dream of an entire OS supporting this.
Regarding Vim fluency spoiling IDEs, I could not bear writing C# code in VS without purchasing the $99 ViEmu ...and that's coming from someone that drives a 1987 F-150.
But how would you feel if you worked as a carpenter 8+ hr/day for 10 years and then realized you had been using a dull saw the whole time? Or that you were doing things in a slightly wrong way which gave you blisters or split the wood?
You might even want to tell other people about it...
I don't think using an Apple brand computer vs. another brand really makes that much of a difference to anything except taste.
Got it.