Live data from Hacker News

Vimcasts

vimcasts.org

31–40 of 43 posts

Re: Vimcasts

#31
post #7

Earlier quoted context omitted.

One note: please activate page caching. looks like your slicehost is quite busy atm.

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.

Re: Vimcasts

#32
post #7

Earlier quoted context omitted.

One note: please activate page caching. looks like your slicehost is quite busy atm.

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.

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.

Re: Vimcasts

#33
Personally, I've found some of the advice dubious or just plain wrong (e.g. trying to map control plus number key). But some of it looks terrific.

Re: Vimcasts

#35
post #32

Earlier quoted context omitted.

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.

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.

Radiant uses Rack::Cache behind the scenes, so it still needs to be running.

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...

Re: Vimcasts

#37
post #24

Earlier quoted context omitted.

What i like about vim's UI is that it's very reduced to a minimum. New users have no idea how powerful it is.

Come to the Dark Side. We have buffers.

I just watched the video entitled "Working with Buffers" so I don't quite get your reference

Re: Vimcasts

#38

From the about page: >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 the…

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!

Re: Vimcasts

#39
post #33

Personally, I've found some of the advice dubious or just plain wrong (e.g. trying to map control plus number key). But some of it looks terrific.

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.

Re: Vimcasts

#40
post #29

Earlier quoted context omitted.

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, so…

Ah, my mistake. I meant registers, not buffers. :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…

I've had that problem, here's what I do:

: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 so instead of :n, my .vimrc has:

:map :n " next file, with control-n :map :N " prev file, with control-p

Post reply on HN