4 ms·

I use vim for coding just about every day, and as a rule, I try not to install plugins unless I really need/want it. Reason being is if, on occasion, I need to

by jpk 14y ago

I use vim for coding just about every day, and as a rule, I try not to install plugins unless I really need/want it. Reason being is if, on occasion, I need to do a little editing inside an ec2 instance, or whatever, I don't want to type `vi` at the shell and get a different editor than the one I use every day. So I try to keep it as stock as possible, while allowing enough customization to be productive and comfortable. Anyway, that said, Ctrl-P makes the cut. :)

sophacles 14y ago
Why not put a git repo of your .vim/ somewhere publicly accessible, then just check it out wherever you need to use it? Going further, just have a simple to remember repo address with all your dotfiles... or even just an init script that bootstraps your environment for you? A good custom environment, catering to your preferences can help a lot. It is a bit of a pain to initially set up, but then it's just a command or two at first login, and you have your environment everywhere.
- shortlived 14y ago
  This is a great idea if you are always running on a modern system. I learned Vi (and later vim) out of necessity because I was programming on Solaris 9 and USS (unix on z/os) and modern Vim was just not available.
- jpk 14y ago
  I've thought about it, but in the context of, "I'm reformatting this disk, and I need to back up my home directory to have after I'm done," since I would cry many tears if I hosed my ~. But in that case, I just make a copy of it somewhere instead of putting it in git, or whatever. Putting it under version control for more casual reasons, though, sounds like a good idea. Plus, you get revision history! I might just do that. :) Either way, I don't think I'd go much further from stock than I already do because like shortlived illustrates, there's just sometimes you have to use the vanilla version of whatever you're dealing with, no matter what you do.
  - weaksauce 14y ago
    I like to think of it as maximizing the following equation. How fast is my main vim going to be * percent of my vim editing time vs. how fast a one off system is * performance penalty for sometimes trying the functions that you have in the main system * the percentage time spent editing in that system. I find that the most time is spent for me in my main vim session on my computer and the ancillary servers do not need the more advanced text editing features because I am just not in them that often.
    - jpk 14y ago
      Oh, I agree fully. Optimize for the common case. This is why I make a few exceptions like Ctrl-P. But in this situation, there's one variable missing: the urgency with which off system editing happens. If a machine is blow'd up and stuck in single-user mode, and the only way to get it back is a heroic vi session, or if somebody screwed up an apache config and your site is bouncing customers, or whatever, those are the times you don't need the added frustration of an unfamiliar editor. That, and I didn't find stock vim to be uncomfortable once I learned it, so I don't feel like I'm sacrificing much to get the luxury of my editor working pretty much the same everywhere in the universe.
      - sophacles 14y ago
        In my experience, as long as I don't customize the regular keymappings, switching to a vanilla vim is annoying, but not crippling. About a minute of "dammit I can't use bufexplorer or :Ack" and I'm on my way. A large number of my vim keymaps are programming language specific, so this reduces the level of annoyance even further, as I won't be editing a lot of code on a "burning" server, mostly config files. Any code that is changed, will be a bit annoying, but the changes are usually not big enough that it requires a ton of fancy editor-fu anyway. The biggest thing I have found with all of this tho, is that everyone has different prefs, so if you're pretty happy with the way it's working, don't change because some folks on the internet are suggesting it, but if sounds interesting, give it a try, the worst that happens is you have to revert to the old way. (different optimization problem here I guess :) )
      - 14y ago
Produce 14y ago
I was a vim minimalist for a short while for the same reasons. They make sense in theory. In practise, all you really need to remember for regular vi(m) is :e. All the rest of the motions and commands you'll be using anyway. The amount of productivity gained from a customized vim config > the amount of productivity gained from remembering a couple of commands in case you need to edit on another box. And that's how learned to stop worrying and love the bomb.
- lloeki 14y ago
  I can indeed safely degrade myself to use pure-vim easily enough, but the only one that bites me when missing every now and then is vim-surround.
njharman 14y ago
Optimize for the common path (editing code) and not the exception "on occasion, need to edit with raw vim." It might make sense for a consultant admin who is managing dozens of systems and 100's of boxes. But for a developer not crafting and utilizing the best tool chain possible is just a waste.
slurgfest 14y ago
I have heard this argument over and over again. As a heavy plugin user who routinely connects to machines without the plugins, it is not an issue for me at all. And I learned vim while using tons of plugins. But obviously if you are depending heavily on something like Cream (which makes its behavior more like gedit or something, insert mode all the time) you are going to have a tough time adjusting. Very few plugins change vim's behavior in that kind of fundamental way, however. Life is short. Use the plugins you want to use.

by jpk 14y ago

sophacles 14y ago

Why not put a git repo of your .vim/ somewhere publicly accessible, then just check it out wherever you need to use it? Going further, just have a simple to remember repo address with all your dotfiles... or even just an init script that bootstraps your environment for you? A good custom environment, catering to your preferences can help a lot. It is a bit of a pain to initially set up, but then it's just a command or two at first login, and you have your environment everywhere.

shortlived 14y ago
This is a great idea if you are always running on a modern system. I learned Vi (and later vim) out of necessity because I was programming on Solaris 9 and USS (unix on z/os) and modern Vim was just not available.
jpk 14y ago
I've thought about it, but in the context of, "I'm reformatting this disk, and I need to back up my home directory to have after I'm done," since I would cry many tears if I hosed my ~. But in that case, I just make a copy of it somewhere instead of putting it in git, or whatever. Putting it under version control for more casual reasons, though, sounds like a good idea. Plus, you get revision history! I might just do that. :) Either way, I don't think I'd go much further from stock than I already do because like shortlived illustrates, there's just sometimes you have to use the vanilla version of whatever you're dealing with, no matter what you do.
- weaksauce 14y ago
  I like to think of it as maximizing the following equation. How fast is my main vim going to be * percent of my vim editing time vs. how fast a one off system is * performance penalty for sometimes trying the functions that you have in the main system * the percentage time spent editing in that system. I find that the most time is spent for me in my main vim session on my computer and the ancillary servers do not need the more advanced text editing features because I am just not in them that often.
  - jpk 14y ago
    Oh, I agree fully. Optimize for the common case. This is why I make a few exceptions like Ctrl-P. But in this situation, there's one variable missing: the urgency with which off system editing happens. If a machine is blow'd up and stuck in single-user mode, and the only way to get it back is a heroic vi session, or if somebody screwed up an apache config and your site is bouncing customers, or whatever, those are the times you don't need the added frustration of an unfamiliar editor. That, and I didn't find stock vim to be uncomfortable once I learned it, so I don't feel like I'm sacrificing much to get the luxury of my editor working pretty much the same everywhere in the universe.
    - sophacles 14y ago
      In my experience, as long as I don't customize the regular keymappings, switching to a vanilla vim is annoying, but not crippling. About a minute of "dammit I can't use bufexplorer or :Ack" and I'm on my way. A large number of my vim keymaps are programming language specific, so this reduces the level of annoyance even further, as I won't be editing a lot of code on a "burning" server, mostly config files. Any code that is changed, will be a bit annoying, but the changes are usually not big enough that it requires a ton of fancy editor-fu anyway. The biggest thing I have found with all of this tho, is that everyone has different prefs, so if you're pretty happy with the way it's working, don't change because some folks on the internet are suggesting it, but if sounds interesting, give it a try, the worst that happens is you have to revert to the old way. (different optimization problem here I guess :) )
    - 14y ago

Produce 14y ago

I was a vim minimalist for a short while for the same reasons. They make sense in theory. In practise, all you really need to remember for regular vi(m) is :e. All the rest of the motions and commands you'll be using anyway. The amount of productivity gained from a customized vim config > the amount of productivity gained from remembering a couple of commands in case you need to edit on another box. And that's how learned to stop worrying and love the bomb.

lloeki 14y ago
I can indeed safely degrade myself to use pure-vim easily enough, but the only one that bites me when missing every now and then is vim-surround.

njharman 14y ago

Optimize for the common path (editing code) and not the exception "on occasion, need to edit with raw vim." It might make sense for a consultant admin who is managing dozens of systems and 100's of boxes. But for a developer not crafting and utilizing the best tool chain possible is just a waste.

slurgfest 14y ago

I have heard this argument over and over again. As a heavy plugin user who routinely connects to machines without the plugins, it is not an issue for me at all. And I learned vim while using tons of plugins. But obviously if you are depending heavily on something like Cream (which makes its behavior more like gedit or something, insert mode all the time) you are going to have a tough time adjusting. Very few plugins change vim's behavior in that kind of fundamental way, however. Life is short. Use the plugins you want to use.