>Vimcasts is produced by Drew Neil (aka nelstrom), who came to Vim from TextMate. He made the switch when starting work at a company that uses Linux workstations. His choice of text editor was influenced by collegues.
Textmate is great, but this is something that concern me as well, as sooner or later I'll have to start over with a new editor. Hopefully I'll be able to learn something through these screencasts.
I, and as have a lot of others, went from TextMate to Vim. I was really looking into something fresh, and learning Vim has been a breath of fresh air.
I found it comparable to when I switched over from SVN to Git, it really made me revitalized my programming, I was looking forward to work with my new tools! I had that same feeling when picking up Vim, so I can wholeheartedly recommend!
Vimcasts.org runs on Radiant CMS, which has page caching enabled by default. My problem was too many app instances spinning up. I've limited the PassengerMaxPoolSize and PassengerMaxInstancesPerApp both to 2, which seems to have fixed it.
I appreciate this burst of traffic to help me get to the bottom of this.
I wonder why you're running a clean site like vimcasts.org on a full-blown CMS. Imho this scenario longs for simpler solutions. Static site generators - in the Ruby universe: toto, nanoc, webby - come to mind.
Well, I guess your passenger/apache is not configured right to deliver the generated static files without using ruby or passenger besides your MaxInstances/PoolSize options.
I remember some issues with passengers and page caching (on nginx e.g.) which needed some tweaks.
I use the arg list. I looked into buffers a while back, but they seemed overcomplex for what I need (same with windows). Checking the vim help just now, buffers and arglist seem (mostly) equivalent.
I'm curious: do you find there's specific advantages of buffers over the arglist? And, do you use buffers as well as, or instead of, the arglist?
The only problem I find is that if I start two vims in different xterms, sometimes I'll want to paste between them - so I need to use the system clipboard, instead of vim.
As to your "I'm curious" question, I use both. Mostly arglist, and I resort to buffers when the arglist has gone squirrely (editing an additional file after starting with a number of files, e.g.).
For example, edit a small number of files (vi *).
:files will show you the list of files.
Repeating :n will take you through each file.
:e newfile to create a new file
:files will show you the list, with newfile at the end.
:rew to rewind the list
:n will get you to the last file on the original list, but not to newfile.
will do the same as :e, but also add it to the arglist. You can prefix with a number to insert it at a particular position, especially :0arge and :99arge for first and last respectively. It only adds one at a time; several can be added with :arga (including recursive wildcards such as /*.java)
:argd %
will delete the current file (which % expands to) from the arglist.
BTW: I dislike pressing : and <CR> so instead of :n, my .vimrc has:
:map <C-n> <Esc>:n<CR> " next file, with control-n
:map <C-p> <Esc>:N<CR> " prev file, with control-p
Of course - and you're not the only one asking. The latest episode on modal editing ("the newbie killer") is a step back to basics. However, I don't intend to cover the material that you can find in the vimtutor.
It's not nice to downvote a factual statement (that there is some advice that just doesn't work) without providing a counter-argument.
Seriously, vim doesn't handle maps for ctrl-1, ctrl-2, etc. or ctrl-shift-[, etc. because terminals don't have a way to represent them to running programs. (Technically, xterm has a mode, but no programs understand it.) And gui vim doesn't handle them (though, it could) because that would be too different from what terminal vim can do.
Glad to see a vimcasts site, more perspectives on vim are always welcome. I saw in the comments that you're using randiant cms, one thing you might want to check out is that the source code for railscasts.com is open source and is a pretty solid video cast site.
42 comments
[ 6.7 ms ] story [ 94.9 ms ] threadLooks much better in Firefox at the reduced size, but you'll probably still want to right-click and View Video to see it at its best.
http://code.google.com/p/chromium/issues/detail?id=19113
Are you running the very latest nightly code?
Also, thanks for revealing this "open Video in new tab" feature I've never seen before. Chrome is very pleasing in this manner.
>Vimcasts is produced by Drew Neil (aka nelstrom), who came to Vim from TextMate. He made the switch when starting work at a company that uses Linux workstations. His choice of text editor was influenced by collegues.
Textmate is great, but this is something that concern me as well, as sooner or later I'll have to start over with a new editor. Hopefully I'll be able to learn something through these screencasts.
I found it comparable to when I switched over from SVN to Git, it really made me revitalized my programming, I was looking forward to work with my new tools! I had that same feeling when picking up Vim, so I can wholeheartedly recommend!
I appreciate this burst of traffic to help me get to the bottom of this.
I remember some issues with passengers and page caching (on nginx e.g.) which needed some tweaks.
I'm sure there's some reason it doesn't use Rails static caching, but even having used Radiant I'm not sure what it would be...
I'm curious: do you find there's specific advantages of buffers over the arglist? And, do you use buffers as well as, or instead of, the arglist?
The only problem I find is that if I start two vims in different xterms, sometimes I'll want to paste between them - so I need to use the system clipboard, instead of vim.
:help registers
As to your "I'm curious" question, I use both. Mostly arglist, and I resort to buffers when the arglist has gone squirrely (editing an additional file after starting with a number of files, e.g.).
For example, edit a small number of files (vi *).
:files will show you the list of files.
Repeating :n will take you through each file.
:e newfile to create a new file
:files will show you the list, with newfile at the end.
:rew to rewind the list
:n will get you to the last file on the original list, but not to newfile.
:bn will then get you to newfile.
:arge
will do the same as :e, but also add it to the arglist. You can prefix with a number to insert it at a particular position, especially :0arge and :99arge for first and last respectively. It only adds one at a time; several can be added with :arga (including recursive wildcards such as /*.java)
:argd %
will delete the current file (which % expands to) from the arglist.
BTW: I dislike pressing : and <CR> so instead of :n, my .vimrc has:
:map <C-n> <Esc>:n<CR> " next file, with control-n :map <C-p> <Esc>:N<CR> " prev file, with control-p
That reminded me of this quote from Star Wars Episode VI: "You don't know the power of the Dark Side."
Which reminded me of the bumper sticker or T shirt: "Come to the Dark Side. We have cookies."
Which led to my comment: "Come to the Dark Side. We have buffers."
Buffers isn't important, except as something Vim has that can substitute for cookies.
The tutorial video itself is well done.
Following the video is a concise recap of what was covered in the video.
At the end is a short, relevant list of "learn more" resources.
Well done.
Seriously, vim doesn't handle maps for ctrl-1, ctrl-2, etc. or ctrl-shift-[, etc. because terminals don't have a way to represent them to running programs. (Technically, xterm has a mode, but no programs understand it.) And gui vim doesn't handle them (though, it could) because that would be too different from what terminal vim can do.