It's definitely a problem All Vi/Vim users know well; and, it's precisely why I don't install these "vim mode" plugins / extensions / whatever for other software. Simply put: no matter what they do, it's still not actually Vim. And honestly, I'd rather be forced to do a complete mental shift into a "plain editor" mode rather than have to wrestle with "will this particular combination of Vim commands work in this pseudo-Vim world?"
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. :)
I started using VIM 3 months ago. And now I can't fucking use anything else. The ergo gains of vim are so rediculously awesome, and NOBODY else does VI right, other than VI. Even Sublime 2, it has vintage mode but its not VI, it's missing most of the magic. This is why we need a new VI. One that has better syntax highlighting, one that can use something other than VIMScript AND STILL support all of vimscript. Something with better graphics like what Sublime 2 has, but still lose nothing of VIM's power.
This [1] is an attempt to do just that. I haven't really looked at the source, but from what I gather it is a way to combine keymaps, actions, parsers, and syntax grammars however you like. There's also a vi mode (don't know how complete) and I think the modular approach they've taken is the way to go.
urgh; I feel that the last thing we need is to couple our editors even more strongly to the flavors of the month (and 500mb+ of dependencies). I wish these things were more ecumenical...
We are speaking in a context set by vi/vim (remember, that was the jumping off point for promoting yi here).
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?
I... have absolutely no idea what you're trying to say. It's not worth ever using a language if there's an older one around? Are you saying you don't want to switch editors unless the new one is written in FORTRAN?
Better syntax highlighting? For what language? In all honesty, it's not super-tough to write your own syntax for any language. If you do it, release it on github and others will probably be willing to contribute.
Vim has support for scripting against Python and Ruby in addition to VimScript.
Better graphics? For what purpose? For displaying text?
Parsing C++ isn't required if all you are doing is syntax coloring.
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.
Any syntax highlighting scheme which does not leverage a language parser is woefully limited. If you're satisfied with a scattering of heuristics, great; you'll find satisfaction in a much wider set of tools. Myself, I want syntax highlighting that doesn't break as soon as I do something unusual, and which is capable of more than identifying keywords.
Given that vim is open source, I'm not sure why you think hard-coded syntax highlighting would be impossible for me to modify.
Mind the context: the guy said there needed to be a "new VI" to have "better" syntax highlighting (whatever specifically he meant by that). You broke in to emphasize how tough it is to parse C++, which is true, but not entirely relevant; the person you replied to was simply pointing out that it's easy to reconfigure vim's syntax highlighting to almost any requirement. Which is true, by the way.
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)
Well, vim cannot syntax highlight markdown. Period.
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...).
vim already supports things other than vimscript (e.g. perl, ruby, python). Depends on what your OS packages provide, or compile it yourself (really not too hard).
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.
* 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-v
There is no reason to use xsel. try "+p or "* p
to pull into the clipboard, try "+y or "* y
(edit: the spaces are just me trying to escape the asterisks for HN)
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.
The easiest thing to do here would likely be to make an alias that runs vim -c s/^/\\=@\* which opens vim with the text from "* on the first line. You could even add a mapping like gg"* yG:qa!<Cr> to yank the new text and close vim(the space after the asterisk is to escape it, of course).
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).
This is a great idea, for optimizing this pathway. With a sufficiently programmable desktop environment, you can probably wrap it all up into one hotkey (including the select-all, cut, and paste in the original window). I'm not sure if it's quite worth doing, on first principles, but I may take a swing at it for the practice in customizing my setup.
although I've used vim for a while now, I still feel like chuckling when I see something like 'gg"* yG:qa!<Cr>' written out, because of how ridiculous it looks to anyone who doesn't use vim.
I know just what you mean, it looks absolutely ridiculous. I occasionally send coworkers very long vim macros just for the enjoyment of explaining how useful some 100-character line of gibberish is.
> try "+p or "* p to pull into the clipboard, try "+y or "* y
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 made a more detailed post below, but I would think an alias to something like vim -c s/^/\\=@\* (or @\+ I'm not sure which register you'd need to use) would be your best bet for fast editing: it should let you open vim with text from your clipboard already inserted on the first line.
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 - vimperator
Eh, most of the time what I write in a text field is short enough I'm not really going to be editing it. When I find myself writing paragraphs, I do something like the above. I agree that it's not ideal, but it suffices.
The biggest pain point I have with the constant copying back and forth is when I'm editing something that live previews in the text field or that needs to be executed. There are times when I just want to embed vim when editing code in a browser.
I use the pentadactyl extension for firefox, and I've added the emacs hotkeys <C-a>, <C-e>, <C-n>, <C-p>, <C-f>, <C-b>, <M-f>, and <M-b> to insert mode so that I can at least move between lines and words without much problem. It's not vim, but it makes things like writing this comment a lot easier for me.
Also having <C-p> and <C-n> as up and down means that moving between search suggestions on sites is really easy, which is nice.
I've been trying to switch my programming to vim, I don't know why (in fact I know, because everybody everywhere promises it's the single greatest thing ever made). I got to learn a couple of commands, enough to feel quite comfortable with it. But my major problem, what refrains me from using it for everything, is its lack of support for refactoring. In fact, if I could find a plugin that can properly handle 'renaming' in a couple of common languages, I'd be sold. But I searched, many times, and didn't find. Same for 'intellisense', which is somewhat emulated with 'omnicompletion' that I have all set up, but it's not context-sensitive...
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?
These are honestly the two biggest criticisms I hear about Vim; and, if they're features you really do use often, I don't really have any good response in store.
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).
>That said, the only type of projects that I've ever felt I really used Intellisense were sprawling Java applications.
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 spend all day in vim writing python, and I've got to agree that refactoring and completion are two of vim's weakest points(I have heard that ropevim is pretty good but I never got into it).
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.
Do you refactor so often that this actually becomes one of your main issues? Simple refactoring can be done with :argdo or :bufdo in combination with :%s. For more advanced cases, I know there are plugins for at least some languages. I use ropevim (http://rope.sourceforge.net/ropevim.html) for Python, and its refactoring tools are very good. I suspect there are similar tools for other languages, but I've never used any.
Vim is not the ultimate tool. It is a very efficient and powerful text editor but I would say it is not a replacement for an IDE. However to me the problem with most IDES is the I part. You're stuck with their text editor, their build system, and their tools. I'm certainly not against integrating related tools together, I just would like the ability to access those tools by themselves as well. My ideal IDE would be one that has an integrated environment with all its tools, but with each tool being able to work independently. So if I prefer editing in vim, but I'd like to use the IDE's refactoring, I can set up a script or perhaps a vim plugin that will use the refactoring program provided by the IDE.
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.
When I was doing Java I used Eclipse for Java and vim for everything else. You are correct: Eclipse is better for Java mainly for the refactoring support. Now, I am mainly working with Ruby and use vim exclusively. I have not found any IDE that works well with dynamic languages.
If Eclipse can handle your language, then the eclim plugin will provide renaming, real autocomplete, etc. within vim. It just runs eclipse in the background and exposes functionality to vim.
Thanks for this! This should help out when I finally start hacking something for Android. I've been using vim for simple java projects before, and while NERDTree helps a bit with the forced split over too many files -- it always felt a bit painful.
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 use a combination of Ack (to search for the instances of the code I want to refactor), and Vim's search and replace feature.
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.
Renaming things doesn't take me a significant amount of time in vim and it certainly doesn't account for a significant share of my total time on a project.
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.
As an emacs user, I'm pretty happy to mostly not have this problem.
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.
Readline has vi mode, and it's amazing. I use vi mode in zsh, bash, ruby, python, mysql, etc. and I can't live without it any more.
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.
Yes it's a nice benefit for emacs users that readline offers good emacs-style editing. Although, enough command line tools support vim-style editing too that the level of benefit is not much.
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
Readline also has a vi mode, which I've heard is pretty good.
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.
On the other hand, the feature wouldn't hurt them; if a default user-friendly interface personality is provided with the existing behavior, they don't even have to know that the the system is swappable.
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 started to worry about this as I got older, so a few years ago I got a Kinesis Advantage keyboard at work and home with the control and meta keys mapped to the left thumb buttons backspace/delete. I was able to break the left-pinky control habit by mapping my CAPSLOCK key to a noop.
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.
I'm as guilty as anyone of going deep on various editors and really getting into the weeds of editor automation, configuration, and learning obscure hotkeys and commands. Vim and emacs in particular are great for this. But after many years of programming, I've become really skeptical of the value of this approach. The amount of time I spend actually typing in code is utterly dwarfed by the amount of time I spend thinking about what code should be typed in. Spending lots of time memorizing editor-specific key sequences to save a keystroke here and there is starting to look more and more like an illusion of efficiency, or possibly a net loss if it means constantly having to reach for refcards or struggling with an illusion of inefficiency when using other editors. It makes a lot more sense for people who really do spend more time typing code than thinking about code...I would be fascinated to see some sort of survey as to what that ratio is for programmers in general, and how it affects people's choice of tools.
There is a continuum, and there is an explore/exploit problem.
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.
Thank you. Programming is not an IO-bound problem, and if it is, you're not doing anything interesting.
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.
I actually do find that text manipulation can become the bottleneck in the right environment, at some points in a coding session. Vim won't make you faster while staring at a pair of empty braces thinking about the right algorithm. Vim can make you faster while rewriting a function, moving code around, or typing code that you've already thought through. And I often find that the faster I can get a thought out and stop holding as much state in my head, the faster the next idea comes.
I have a much more interesting problem (I think!).
I wish Vim could read its configuration from a HTTP-URL passed in an environment-variable:
REMOTE_DOTVIM=https://foobar.com/dotvim
I'm dealing with many dozens of hosts and getting my precious dotvim onto all of them is outright impossible. Especially on accounts shared with other people.
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...
Plain curl unfortunately doesn't cut it because that misses .vim, which contains all the goods (plugins etc.).
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.
I use a dotfiles repository on Github to easily get my Vim environment set up on a new machine.
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. ;)
Apart from the obvious snide answer: "You shouldn't share accounts, use sudo." -- I see what you mean.
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.
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.
You deal with dozens of hosts and do not have any way to distribute a file to all of them? Does that imply that you are doing all management of these hosts and their files individually, by hand?
No, it implies that most of the accounts where it is an issue (i.e. root and the app-account) are used by multiple people with potentially conflicting vim-preferences. There are elaborate hacks around that (i.e. identifying users by their ssh-keys) and we actually have one deployed for the app-account. But there are various scenarios where that occasionally fails (e.g. hopping through a bastion host).
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. :)
I see, the account sharing rules out the ordinary way of supporting multiple users.
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.
In terms of Vi(m!) emulation, emacs' evil-mode (http://emacswiki.org/emacs/Evil) is pretty damn complete. The only real issue is properly integrating it with the rest of your Emacs environment.
The broken bindings for ^W and ^U have driven me crazy enough to create a website dedicated to try to document how to fix broken software to properly handle them:
When you see me half ask a question on IRC then quit, or quit repeatedly. ^^^ Switching context between vim & xchat & killing tabs. See also: jjjkkjkkgg
My biggest problem with Vim is the muscle memory I have developed where I hit [esc] after writing text. The problem is that in most programs outside of vim, [esc] means to cancel the operation. Try renaming a file and set it with [esc].
This is avoidable if you use Ctrl-C instead of escape. It works identical to [esc] in all ways except one (the InsertLeave autocommand will not be triggered). If you remap Caps lock to Ctrl, you even get a more ergonomic way of escape, since you don't need to move your hand the way you would to press [esc].
> Two years ago, a heavy bout of coding gave me some wicked wrist problems, and an ergo expert recommended I switch to vim.
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.
They told me all of these things too, most of which I was already doing. Hover your wrists over your keyboard, elbows tucked in at your side, forearms should be parallel with the floor, eye level at the center of your screen, feet flat on the floor, lower legs perpendicular to the floor. But even after maintaining good typing posture for a while (and rearranging my workspace to be more ergo-friendly) the wrist pain didn't go away. It was gone in a week after I stopped using Emacs.
It's far less the control key than the meta key for me.
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.
As a random bit of trivia, tapping esc followed by another key counts as hitting meta for that key. It might be easier to simply slap 'esc x' than try to chord alt-x.
I tried, but to no avail. Even if you move Control, you're still chording and that can twist your hands into funny shapes. Not to mention that I never found a good solution for where to remap Meta to; it got to the point where just hitting M-x was really painful.
As a dirty non-vim-using heathen trying to correct the error of my ways, I'm having trouble adjusting. Is there a good reason to use hjkl for moving the cursor that I'm not aware of by virtue of knowing nothing else? Why not jkl; or ijkl?
This may just be an urban myth but afaik Vim uses hjkl because the terminal[1] that it was originally used to write Vi had a keyboard where the arrows were on those same keys.
Also, the escape key was in the place of the modern day tab key making switching modes much easier.
Once you get used to using vim properly, you'll find that you almost never need to move one character left or right (h or l). It is actually a nice setup that your index and middle fingers are responsible for moving up and down in the file since that is what you will be doing most often. There are much better ways of moving horizontally in the file than one character at a time. You can use w and b to move forward and backward via words which is much more efficient than single characters. You can also use f and F to 'find' a character forward or backward. I typically use that to navigate between method arguments or parentheses. So you can type f, and it will move your cursor FORWARD to the comma. Then just press ; to repeat the search (and go to the next comma). If you want to go backward, do F, and it works the same way, only backward. I'm sure there are better examples but the point is, if you are using h or l often, then there are probably better ways to navigate. Also, this sounds kind of confusing at first (having to remember fFwb; etc), but just learn one at a time and you won't have to think about it after a while. Soon you will find yourself typing an email and accidentally ending up with jjjjjj in random places... :)
This is obviously a problem with getting used to anything you can't always rely on. Vim addiction made me try Pentadactyl and now I find it incredibly painful to use a browser without similiar functionality. It's also unpleasant to use a keyboard whose Caps Lock hasn't been mapped to act as an Esc.
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.
Learning an editor is not like learning typing. You should learn an editor but not be addicted to it. This is just like learning a language.
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.
This is exactly my point, though; being efficient at Vim is unlike using any other editor, and you've invested so much into gaining that muscle memory it's very, very hard to convince yourself that other tools are better. In some way, I am addicted to the efficiency and succinctness of Vim.
Maybe I just don't code enough. I see little advantage to vim or emacs over, say, gedit or kate. What am I missing (besides a need for esoteric hotkeys)?
This question can be answered by just a bit of research using your friend Google. I like sum-it-up by saying that it's all about making your editor work for you as opposed to simply being a blank slate on which you can type.
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.
"work for you" might not be the right message, as that is what IDEs are known for.
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?
I agree; it's tough to write out the semantic difference between an IDE "doing work for you" and Vim "working for you," where the former is tools doing tasks you don't want to do and the latter is the editor providing a language for you to give it instructions in far more evolved way than the primitive text-editing concepts of many other editors.
Both Emacs (reportedly, I use vim) and vim have a system that allows you to be more effective in every thing you do when manipulating text. I cannot give examples for Emacs, but for vi(m) the interface is based around a few basic concepts:
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".
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.
By calling them esoteric, you've demonstrated what you are missing. The keyboard shortcuts are made in such a way that they should feel natural with regard to the task they accomplish. Once you master enough of them, you won't believe how fast you can type and edit code.
I'd argue that it has nothing to do with how fast I can type or edit code. It has to do with how fast I can express ideas.
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!
I don't think the two ideas you are talking about are mutually exclusive. I type and edit code faster in vim, and I'm able to accomplish tasks and put down my thoughts faster as well. One lets me accomplish the other, and vice versa.
Esoteric: Intended for or likely to be understood by only a small number of people with a specialized knowledge or interest.
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.
As a big fan of vim and the hjkl paradigm, I've tried many of the plugins that try to make other software more vim-like. While I can fully understand the feelings of haldean, I've never felt it myself.
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 really want to experience frustration as a vim user, try working on a legacy proprietary Unix box with nothing but old-school vi on it.
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.
The only thing I use Vim for is coding. I use gedit for taking notes and logging my hours. I use OpenOffice/LibreOffice for documents, spreadsheets, invoices, etc. I use the web for most every type of communication from blogging to email to HN comments.
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.
I've been using Pentadactyl with bleeding edge Firefox since its first days and
I definitely agree with you.
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.
I looked at Vimium but was put off by its implementation. It seems that Chrome simply doesn't allow a plugin to be as completely integrated as Firefox.
I don't have this problem, just like I don't have a problem with typing both English and Russian on a single keyboard: my brain have learned to switch contexts. I don't use vim-like plugins for anything. :wq
Slightly related: There were a couple days way back that I really wanted to learn to type on a dvorak keyboard (later lost interest). One of my friends was doing the same (he also later lost interest) and gave me the tip that I should figure out which thumb I generally press spacebar with when typing on a qwerty board (my right thumb) and use my opposite thumb when typing dvorak. I found this worked really well, I was able to seemlessly switch between my mostly-incompetent dvorak typing and my good qwerty typing without any mental effort.
While we are on the topic of keyboards and editors, the FingerWorks TouchStream LP [1] keyboard had various modes including QWERTY and Dvorak, as well as Emacs (!) chording.
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.
[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.
I've heard this in regards to typing speed and it's probably true, though I've never been a fast typist.
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.
Oh come on, you have all your vowels and other frequent letters right there on the home row. There might have been some issues with the studies that were supposed to show Dvorak's superiority, but if you take a cursory glance at the layout it should be immediately obvious that your fingers will need to travel less because the layout conforms much better to the observed frequencies in most languages.
Vowels and frequent letters? For one I am a programmer, not a writer --my frequent keys are widely different than a typist's.
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.
Identifiers in source code are typically base on words, so will share the same distribution of English text to some degree. It should be easy to make a program that takes any text file, and for each character notes how far your fingers would have to move from the home row on a certain layout. This could then quantify the distance on qwerty vs. dvorak. That would provide an interesting empirical verification of this issue.
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.
Since you specifically said “vi users”: The problem is most often – in my experience – that the plugins support only vi functionality, while Vim additions such as text objects are not supported. I love using Vim, but find vi really lacking.
I think it would be cool to have a vi/vim engine that can be added onto editors. The editor would only have to overload simple functions like keyPressed(key), getChar(pos), setChar(pos, c), etc, and the engine would take care of the rest of the vi/vim emulation.
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.
As far as vim with Eclipse goes, I tried out eclim, but I didn't like it too much. You loose features like being able to click on source code lines to create a breakpoint.
I've only used it lightly, but I've been pleased with vrapper so far:
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.
Look up text objects such as i" and a". They're great.
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.
I've still got faith that with enough patience the editor itself can be made ubiquitous.
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.
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?
Vimperator/Pentadactyl's numbered links are doing the same thing for me. Hit the "f" key and anything "clickable" on the screen is overlaid with a number. Type the number and enter and you've "clicked" it. It's ingenious.
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.
My biggest problem with vim is the fanboy base. You all are worse then mac users. (typed from my mbp) Get over it, its an editor, a tool, not the end product.
Yes, it is a tool. And sometimes tools differ in boring ways that make no difference, like they have different colors.
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.
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. :)