8 ms·

It's important to note the context these articles are usually presented in, and also most the responses, which is Vim for developers (or at its most general, Vi

It's important to note the context these articles are usually presented in, and also most the responses, which is Vim for developers (or at its most general, Vim for sustained local use). The reason I bring this up is that there's a whole other set us use that is often overlooked, which is Vim as a standard tool for sysadmins. Any system you connect to will have Vi, and probably Vim. This makes it an ideal tool for sysadmins that might need to connect to tens or hundreds of systems to know how to use, and to have a fairly standardized behavior. In those cases, having a customized config can actually be more of a hindrance, because switching from a highly customized local Vim instance to a stock remote Vi/Vim instance can be jarring. For anyone who is primarily a sysadmin, I would recommend sticking with the default behavior (which is rich, and lends itself to being more and more useful and they become familiar with more an more commands), and making a minimum of local config changes and plugins to suit their needs (it's a trade odd. Just choose wisely). This makes life easier when you spend a significant portion of time on random stock Vim instances (and even if it only saved a modicum of time, it saves a lot of aggravation as you don't feel like you're working with missing limbs). Then again, I've always been one to do develop scripts remotely to help with tasks (all the easier to test int he correct environment), so other people's experiences may differ. I'm primarily doing software engineering now, so I load main vim instance with a fair amount of specialization (but probably less than most).

vram22 8y ago
>It's important to note the context of this article, and most the responses, which is Vim for developers (or at its most general, Vim for sustained local use). The reason I bring this up is that there's a whole other set us use that is often overlooked, which is Vim as a standard tool for sysadmins. >Any system you connect to will have Vi, and probably Vim. This makes it an ideal tool for sysadmins that might need to connect to tens or hundreds of systems to know how to use, and to have a fairly standardized behavior. In those cases, having a customized config can actually be more of a hindrance, because switching from a highly customized local Vim instance to a stock remote Vi/Vim instance can be jarring. That's a great point. I had mentioned something to the same effect, briefly, in the blurb for my vi quickstart tutorial, here: https://gumroad.com/l/vi_quick https://gumroad.com/l/vi_quick I first wrote that tutorial at the request of a couple of Windows system admin friends of mine (at a company where I worked earlier), who were tasked with managing a few Unix boxes, without knowing Unix. They used the tutorial and later told me that it helped them to quickly start using vi to do their work on those boxes, including editing config files, simple shell scripts, etc. Edit: Since vi is mostly a subset of vim, the tutorial works for vim too.
leowoo91 8y ago
Regardless of customization points, I find using Vi after Vim quite confusing.
sl1ck731 8y ago
I do a lot of sysadmin stuff and go crazy when I need to do anything except copy/paste, and insert. I really want to sit down and learn vim for those tasks but usually just end up opening nano and going about my business. One problem I've found with vim is some weird character buffer thing happens where my text stops displaying or something. I've never investigated it but its probably SSH itself.
- cillian64 8y ago
  Do you accidentally press Ctrl+s to try and save? That tells the terminal to stop sending text (eg if a long command output was scrolling by). Try Ctrl+q to fix it next time it happens.
  - sl1ck731 8y ago
    It is entirely possible. I'll have to be more cognizant next time it happens and catch myself if that's the case.
  - bonoboTP 8y ago
    Newer versions of Nano actually do save the file on CTRL+S.
    - wolco 8y ago
      Didn't pico as well?
  - fiddlerwoaroof 8y ago
    I believe this fixes that behavior while vi is open: https://github.com/fiddlerwoaroof/dotfiles/blob/master/zsh/zsh_plugins/dependencies/vi-tty-fix.zsh https://github.com/fiddlerwoaroof/dotfiles/blob/master/zsh/z...
thisacctforreal 8y ago
FWIW this article specifically is mainly for common traps (e.g. spamming arrow keys) in vanilla vim.
- kbenson 8y ago
  Yes, I changed my initial sentence slightly (you can see the difference in the quote of the original that vram22 included in their reply) to reflect my real intent is to call attention to the context many Vim articles and comments, and not necessarily this specific article. I didn't append an edit note as I often do (even though it was more than an hour after initially commenting) because I considered it a small clarification of my intent, but one was probably warranted. I'll consider your comment and this reply as that edit note now. :)
colordrops 8y ago
I thought that this would be the case and initially stuck mostly with defaults, but it didn't really turn out to be true. You won't forget how to use vanilla vim unless you really go crazy and replace all keystrokes. Turns out you don't forget how to play clarinet after learning saxophone.
- kbenson 8y ago
  I didn't mean to give the impression that you forget vanilla Vim, more that it becomes somewhat painful to use as you deal with the absence of what you've come to expect. It doesn't really matter much whether you use tabs or spaces, or how many spaces a tab key (or tab character) represents, but having to swap between them multiple times a day gets... tiresome. There's a fluidity that comes with your tool behaving how you expect, and a time of acclimation when it changes. Whether the benefits of either keeping your config close to stock to reduce this acclimation period or highly customizing your personal Vim to be as efficient as possible is the better solution probably depends on the individual and the relative amount of time spent in each environment. I'm not really urging one approach over the other, but rather noting that one should be cognizant of this, as it may allow for better decisions at different times. I, for one, found certain Vim customizations to be not worth the effort at one point when I was doing a lot of remote Sysadmin work, but worth investigating more when my time in Vim shifted more towards being used in one main instance. As a simple example, if you spend 80%-90% of your time on remote servers, how useful is it to install Nerdtree on your main instance and spend the time configuring and learning how to use it well? Are the keys to Vim split windows and resizing better, or perhaps figuring out how to do that in screen/tmux is more effective a that time (can that be assumed to be on the servers?). If nothing else, I think it helps explain why some people are so enamored of some Vim plugins, while others try them and consider them "meh".
  - fiddlerwoaroof 8y ago
    I’ve always found it rather trivial to scp my config onto the server, initialize the package manager and have it available everywhere.
sevensor 8y ago
> I load main vim instance with a fair amount of specialization (but probably less than most) Perhaps it's just that the people who diligently curate their .vimrcs are more prone to talk about it than people who use stock or minimally configured vim. I can tell you my .vimrc right now without looking at it. se sm se hls se number se ts=4 se sw=4 se expandtab It's not very exciting. Nobody ever writes a blogpost on the virtues of a vimrc that looks like this one.
- lwf 8y ago
  The minimalism reminds me of http://openbookproject.net/pybiblio/tips/elkner/vim4python.php http://openbookproject.net/pybiblio/tips/elkner/vim4python.p... , which was written by my CS teacher from high school, and has survived me ~10 years.
- kbenson 8y ago
  Ha, I see that your .vimrc is almost identical to mine in functionality, even if mine is riddled with mostly superfluous additions and lots of comments. What you've got there though is probably what I would consider the core things I would need to set in vim to get my desired experience on a new workstation if I didn't have my own .vimrc to download, all the way down to the number of spaces for expanded tabs. The rest of the stuff I have boils down to history size, a fixup for backspace in insert, default paste mode and quick key to toggle it, how far from margins to start scrolling, and turning off swap files so editing very large files is easier. Oh, and the Pathogen init stuff, for which I have usually have no modules installed (but I test out stuff occasionally), but there it sits.
- dotancohen 8y ago
  I've got a decade-and-a-half .vimrc that I stopped using last year. I used to rsync it up to other machines before I would SSH into them. Now that I've gotten out of it, I see that there are only a few small customizations that I really enjoy, but none that I need. And I can now use VIM on any machine.
- cliff_badger 8y ago
  Just to make it more efficient :) "instead of se number se nu
gameswithgo 8y ago
if you dump your customizations into github you can customize on whatever server pretty quick. or at least some subset of your settings that would be safe to pull down on the servers you work with.
simula67 8y ago
I agree. I prefer graphical IDEs which plays well with my operating system for software development. However, you still need to know just enough vi in case you are remoted into someone else's computer
ams6110 8y ago
Yes, any Unix-like system will almost certainly have vi available. I'm a emacs use for 3 decades but I know enough vi to make small changes to config files. Was never able to adopt it as my main editor. The bifurcated input/command modes always trip me up.
isostatic 8y ago
Ubuntu 1804 comes with vim 8.0, rather than 7.4 Not sure if it's ubuntu or vim, but it comes with some really annoying changes that haevn't been this jarring since moving from solaris-vi to the vim bundled with ubuntu (vim-nox) over a decade ago. The two most annoying things I really noticed and massively reduced my efficency 1) Get about 6 lines from the bottom and the cursor no longer moves. 2) Search moves the window as you're typing It really pissed me off
- Olreich 8y ago
  1) That’s scrolloff, `set scrolloff=0` to remove this function altogether (I keep mine set to 2) 2) That’s incsearch, `set noincsearch` to turn it off.
  - isostatic 8y ago
    Oh sure, but it means having to have a .vimrc for consistency. My own desktop's vimrc has a few useful shortcuts (F5 for example to "compile" a graphviz file to dot -T x11 -- my VB3 roots showing), but the majority of vim use across the estate has never needed it before. Fortunately I do have a facility to distribute .vimrc to undo these disastrous changes, but changing the default behaviour was rather annoying for an editor that is so ubiquitous.
- _bohm 8y ago
  I had the same initial reaction to 2) (incsearch) at first after having to work in a shared environment with it enabled. After a little while getting used to it I found it actually sped up my workflow quite a bit! YMMV, but you may find it worth the time to leave it on a little longer and see if it works for you.
Tehchops 8y ago
I do not understand the: "don't customize your VIM, what if you have to use vi/vim on a server?" trope. I submit that if you're having to log into individual servers enough to make those kinds of changes, you're already engaged in a systems management anti-pattern. Code up some CM/automation to handle that. You can probably write that code from your workstation, with your more customized Vim. :-)
- kbenson 8y ago
  Well, part of the reason you are having trouble understanding it is that you've simplified it all the way down to a trope, which necessarily misses a lot of the nuance of what I sad. I mean, I don't even agree with "don't customize your VIM, what if you have to use vi/vim on a server?", so why would I expect anyone else to? If I had to distill my point down to a sentence, it would be "be cognizant of your tools and their usage paradigms, and whether large customizations to one paradigm and how it might affect the overall usability, or your perception thereof, of the others." Yes, it's wordy, but that's simply because not everything is easily reduced to a pithy one-liner, at least not without a large loss of context.
  - Tehchops 8y ago
    I don't think I'm missing any nuance. You wrote: > For anyone who is primarily a sysadmin, I would recommend sticking with the default behavior Am I reading that wrong? "Don't customize the default behavior if you're a sysadmin" Do you not agree with what you wrote? I'm simply arguing that, as a sysadmin today, you're far better served eliminating the need for N node access to make changes, and using your customized local config to push changes to a repository that is applied by a CM-esque system.
    - kbenson 8y ago
      The entire sentence was (including typo of "trade odd" instead of "trade off"): For anyone who is primarily a sysadmin, I would recommend sticking with the default behavior (which is rich, and lends itself to being more and more useful and they become familiar with more an more commands), and making a minimum of local config changes and plugins to suit their needs (it's a trade odd. Just choose wisely). The key (corrected) part you're missing is "it's a trade off. Just choose wisely." I go into more detail on that in subsequent comments to other replies. > I'm simply arguing that, as a sysadmin today, you're far better served eliminating the need for N node access to make changes, and using your customized local config to push changes to a repository that is applied by a CM-esque system. That good for many things, but not really an adequate solution for diagnosing a problem under stress.

vram22 8y ago

>It's important to note the context of this article, and most the responses, which is Vim for developers (or at its most general, Vim for sustained local use). The reason I bring this up is that there's a whole other set us use that is often overlooked, which is Vim as a standard tool for sysadmins. >Any system you connect to will have Vi, and probably Vim. This makes it an ideal tool for sysadmins that might need to connect to tens or hundreds of systems to know how to use, and to have a fairly standardized behavior. In those cases, having a customized config can actually be more of a hindrance, because switching from a highly customized local Vim instance to a stock remote Vi/Vim instance can be jarring. That's a great point. I had mentioned something to the same effect, briefly, in the blurb for my vi quickstart tutorial, here: https://gumroad.com/l/vi_quick https://gumroad.com/l/vi_quick I first wrote that tutorial at the request of a couple of Windows system admin friends of mine (at a company where I worked earlier), who were tasked with managing a few Unix boxes, without knowing Unix. They used the tutorial and later told me that it helped them to quickly start using vi to do their work on those boxes, including editing config files, simple shell scripts, etc. Edit: Since vi is mostly a subset of vim, the tutorial works for vim too.

leowoo91 8y ago

Regardless of customization points, I find using Vi after Vim quite confusing.

sl1ck731 8y ago

I do a lot of sysadmin stuff and go crazy when I need to do anything except copy/paste, and insert. I really want to sit down and learn vim for those tasks but usually just end up opening nano and going about my business. One problem I've found with vim is some weird character buffer thing happens where my text stops displaying or something. I've never investigated it but its probably SSH itself.

cillian64 8y ago
Do you accidentally press Ctrl+s to try and save? That tells the terminal to stop sending text (eg if a long command output was scrolling by). Try Ctrl+q to fix it next time it happens.
- sl1ck731 8y ago
  It is entirely possible. I'll have to be more cognizant next time it happens and catch myself if that's the case.
- bonoboTP 8y ago
  Newer versions of Nano actually do save the file on CTRL+S.
  - wolco 8y ago
    Didn't pico as well?
- fiddlerwoaroof 8y ago
  I believe this fixes that behavior while vi is open: https://github.com/fiddlerwoaroof/dotfiles/blob/master/zsh/zsh_plugins/dependencies/vi-tty-fix.zsh https://github.com/fiddlerwoaroof/dotfiles/blob/master/zsh/z...

thisacctforreal 8y ago

FWIW this article specifically is mainly for common traps (e.g. spamming arrow keys) in vanilla vim.

kbenson 8y ago
Yes, I changed my initial sentence slightly (you can see the difference in the quote of the original that vram22 included in their reply) to reflect my real intent is to call attention to the context many Vim articles and comments, and not necessarily this specific article. I didn't append an edit note as I often do (even though it was more than an hour after initially commenting) because I considered it a small clarification of my intent, but one was probably warranted. I'll consider your comment and this reply as that edit note now. :)

colordrops 8y ago

I thought that this would be the case and initially stuck mostly with defaults, but it didn't really turn out to be true. You won't forget how to use vanilla vim unless you really go crazy and replace all keystrokes. Turns out you don't forget how to play clarinet after learning saxophone.

kbenson 8y ago
I didn't mean to give the impression that you forget vanilla Vim, more that it becomes somewhat painful to use as you deal with the absence of what you've come to expect. It doesn't really matter much whether you use tabs or spaces, or how many spaces a tab key (or tab character) represents, but having to swap between them multiple times a day gets... tiresome. There's a fluidity that comes with your tool behaving how you expect, and a time of acclimation when it changes. Whether the benefits of either keeping your config close to stock to reduce this acclimation period or highly customizing your personal Vim to be as efficient as possible is the better solution probably depends on the individual and the relative amount of time spent in each environment. I'm not really urging one approach over the other, but rather noting that one should be cognizant of this, as it may allow for better decisions at different times. I, for one, found certain Vim customizations to be not worth the effort at one point when I was doing a lot of remote Sysadmin work, but worth investigating more when my time in Vim shifted more towards being used in one main instance. As a simple example, if you spend 80%-90% of your time on remote servers, how useful is it to install Nerdtree on your main instance and spend the time configuring and learning how to use it well? Are the keys to Vim split windows and resizing better, or perhaps figuring out how to do that in screen/tmux is more effective a that time (can that be assumed to be on the servers?). If nothing else, I think it helps explain why some people are so enamored of some Vim plugins, while others try them and consider them "meh".
- fiddlerwoaroof 8y ago
  I’ve always found it rather trivial to scp my config onto the server, initialize the package manager and have it available everywhere.

sevensor 8y ago

> I load main vim instance with a fair amount of specialization (but probably less than most) Perhaps it's just that the people who diligently curate their .vimrcs are more prone to talk about it than people who use stock or minimally configured vim. I can tell you my .vimrc right now without looking at it. se sm se hls se number se ts=4 se sw=4 se expandtab It's not very exciting. Nobody ever writes a blogpost on the virtues of a vimrc that looks like this one.

lwf 8y ago
The minimalism reminds me of http://openbookproject.net/pybiblio/tips/elkner/vim4python.php http://openbookproject.net/pybiblio/tips/elkner/vim4python.p... , which was written by my CS teacher from high school, and has survived me ~10 years.
kbenson 8y ago
Ha, I see that your .vimrc is almost identical to mine in functionality, even if mine is riddled with mostly superfluous additions and lots of comments. What you've got there though is probably what I would consider the core things I would need to set in vim to get my desired experience on a new workstation if I didn't have my own .vimrc to download, all the way down to the number of spaces for expanded tabs. The rest of the stuff I have boils down to history size, a fixup for backspace in insert, default paste mode and quick key to toggle it, how far from margins to start scrolling, and turning off swap files so editing very large files is easier. Oh, and the Pathogen init stuff, for which I have usually have no modules installed (but I test out stuff occasionally), but there it sits.
dotancohen 8y ago
I've got a decade-and-a-half .vimrc that I stopped using last year. I used to rsync it up to other machines before I would SSH into them. Now that I've gotten out of it, I see that there are only a few small customizations that I really enjoy, but none that I need. And I can now use VIM on any machine.
cliff_badger 8y ago
Just to make it more efficient :) "instead of se number se nu

gameswithgo 8y ago

if you dump your customizations into github you can customize on whatever server pretty quick. or at least some subset of your settings that would be safe to pull down on the servers you work with.

simula67 8y ago

I agree. I prefer graphical IDEs which plays well with my operating system for software development. However, you still need to know just enough vi in case you are remoted into someone else's computer

ams6110 8y ago

Yes, any Unix-like system will almost certainly have vi available. I'm a emacs use for 3 decades but I know enough vi to make small changes to config files. Was never able to adopt it as my main editor. The bifurcated input/command modes always trip me up.

isostatic 8y ago

Ubuntu 1804 comes with vim 8.0, rather than 7.4 Not sure if it's ubuntu or vim, but it comes with some really annoying changes that haevn't been this jarring since moving from solaris-vi to the vim bundled with ubuntu (vim-nox) over a decade ago. The two most annoying things I really noticed and massively reduced my efficency 1) Get about 6 lines from the bottom and the cursor no longer moves. 2) Search moves the window as you're typing It really pissed me off

Olreich 8y ago
1) That’s scrolloff, `set scrolloff=0` to remove this function altogether (I keep mine set to 2) 2) That’s incsearch, `set noincsearch` to turn it off.
- isostatic 8y ago
  Oh sure, but it means having to have a .vimrc for consistency. My own desktop's vimrc has a few useful shortcuts (F5 for example to "compile" a graphviz file to dot -T x11 -- my VB3 roots showing), but the majority of vim use across the estate has never needed it before. Fortunately I do have a facility to distribute .vimrc to undo these disastrous changes, but changing the default behaviour was rather annoying for an editor that is so ubiquitous.
_bohm 8y ago
I had the same initial reaction to 2) (incsearch) at first after having to work in a shared environment with it enabled. After a little while getting used to it I found it actually sped up my workflow quite a bit! YMMV, but you may find it worth the time to leave it on a little longer and see if it works for you.

Tehchops 8y ago

I do not understand the: "don't customize your VIM, what if you have to use vi/vim on a server?" trope. I submit that if you're having to log into individual servers enough to make those kinds of changes, you're already engaged in a systems management anti-pattern. Code up some CM/automation to handle that. You can probably write that code from your workstation, with your more customized Vim. :-)

kbenson 8y ago
Well, part of the reason you are having trouble understanding it is that you've simplified it all the way down to a trope, which necessarily misses a lot of the nuance of what I sad. I mean, I don't even agree with "don't customize your VIM, what if you have to use vi/vim on a server?", so why would I expect anyone else to? If I had to distill my point down to a sentence, it would be "be cognizant of your tools and their usage paradigms, and whether large customizations to one paradigm and how it might affect the overall usability, or your perception thereof, of the others." Yes, it's wordy, but that's simply because not everything is easily reduced to a pithy one-liner, at least not without a large loss of context.
- Tehchops 8y ago
  I don't think I'm missing any nuance. You wrote: > For anyone who is primarily a sysadmin, I would recommend sticking with the default behavior Am I reading that wrong? "Don't customize the default behavior if you're a sysadmin" Do you not agree with what you wrote? I'm simply arguing that, as a sysadmin today, you're far better served eliminating the need for N node access to make changes, and using your customized local config to push changes to a repository that is applied by a CM-esque system.
  - kbenson 8y ago
    The entire sentence was (including typo of "trade odd" instead of "trade off"): For anyone who is primarily a sysadmin, I would recommend sticking with the default behavior (which is rich, and lends itself to being more and more useful and they become familiar with more an more commands), and making a minimum of local config changes and plugins to suit their needs (it's a trade odd. Just choose wisely). The key (corrected) part you're missing is "it's a trade off. Just choose wisely." I go into more detail on that in subsequent comments to other replies. > I'm simply arguing that, as a sysadmin today, you're far better served eliminating the need for N node access to make changes, and using your customized local config to push changes to a repository that is applied by a CM-esque system. That good for many things, but not really an adequate solution for diagnosing a problem under stress.