Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vim After 11 Years

statico.github.com

Post reply on HN
Print view View original

161–170 of 254 posts

Re: Vim After 11 Years

#161

Post by statico »

SeoxyS wrote: post #80

My single greatest tip to make vim even more amazing is to run it in a tmux session: It makes it super easy to split panes and create new windows for related things you need to do (git stuff, compilation, running tests, running a REPL, etc.)

tmux is fantastic, especially for remote development. However, you can't change a single pane's font size, nor is it easy to select an entire line of text using the mouse (with vertical panes). Thus I suggest iTerm2 for local development if on a Mac.

If you haven't tried multiple panes with multiple font sizes — e.g., smaller font for logs/compiling/long-running, bigger for editing — then that's a world I don't want to live in. (j/k ;)

Re: Vim After 11 Years

#162

Post by statico »

johncoltrane wrote: post #147
statico wrote: post #65

Earlier quoted context omitted.

Good suggestion. In the article, I failed to point out that the advantage of NERDTree is its hierarchal folder view. When a project's directory structure become gigantic it's useful to see the directory structure as you edit.

netrw does that too: hit i to cycle through all the available listing style or add this line to your ~/.vimrc if you want the "tree" style by default: let g:netrw_liststyle = 4

Oh, cool! I'll give it a try, thanks!

Re: Vim After 11 Years

#163

Post by cesarfm »

gnosis wrote: post #87
fatbird wrote: post #24

Every time I read an article like this, it's how a power user installs an array of plugins and customizations to really soup up Vim, which to me kind of misses the point. If you want that level whiz-bang, use Coda or Sublime Text 2 or Eclipse or whatever. I don't recall where I saw this, but someone advised disabling syntax coloring in your editor to remove a crutch (and, secondarily, to visually simplify your enviro…

"If you want that level whiz-bang, use Coda or Sublime Text 2 or Eclipse or whatever. I don't recall where I saw this, but someone advised disabling syntax coloring in your editor to remove a crutch (and, secondarily, to visually simplify your environment)." Perhaps you might enjoy using ed... From: patl@athena.mit.edu (Patrick J. LoPresti) Sender: news@athena.mit.edu (News system) Subject: The True Path (long) Date:…

This made me remember http://xkcd.com/378/

Re: Vim After 11 Years

#164

Post by [deleted] »

statico wrote: post #65
johncoltrane wrote: post #5

netrw comes by default. No need to install NERDTree.

Good suggestion. In the article, I failed to point out that the advantage of NERDTree is its hierarchal folder view. When a project's directory structure become gigantic it's useful to see the directory structure as you edit.

[deleted]

Re: Vim After 11 Years

#165

Post by roryokane »

niggler wrote: post #141
julian37 wrote: post #140

Earlier quoted context omitted.

I'm using http://userscripts.org/scripts/review/121512 , works very well.

Doesn't work in chrome :/ "Apps, extensions, and user scripts cannot be added from this website"

You can make it work in Chrome; there’s a way around the warning. Instructions are in “Steps on adding extensions from other websites” on the Chrome help page linked from that warning: http://support.google.com/chrome_webstore/bin/answer.py?hl=e.... In short, to add the user script, open Tools > Extensions, then drag and drop your downloaded 121512.user.js file into the Extensions tab.

Re: Vim After 11 Years

#166

Post by yurifury »

statico wrote: post #47
jrogers65 wrote: post #2

> Emacs has a useful mode which highlights hexidecimal colors in CSS and SASS with the color represented by the text. http://www.vim.org/scripts/script.php?script_id=2937 > The biggest hole, however, is the lack of refactoring and smart completion. http://eclim.org/

Thanks for the CSS script link!

I would suggest using the https://github.com/ap/vim-css-color instead.

Re: Vim After 11 Years

#167

Post by kunai »

grn wrote: post #150
kunai wrote: post #126

Earlier quoted context omitted.

Trust me, when you have really crappy hardware (Intel Atom 1.3GHz w/ 512MB mem), you will notice the difference. Execution of commands that takes 2-3 seconds on Gnome Terminal will be nearly instant on xterm.

Is rxvt slower? Recently I switched from xterm to rxvt-unicode and it's really great!

Not sure... I'll have to give it a go to see if it really is.

Re: Vim After 11 Years

#168

Post by straws »

ckw wrote: post #108
gfodor wrote: post #88

Some small vim tweaks I've recently been using myself that I find very nice: nmap :write cabbrev w nope Re-map enter to save the file. If you try to do a :w it will yell at you until you take out the cabbrev so you can retrain your muscle memory. Took me about a day to retrain. let g:EasyMotion_leader_key = ';' nmap s ;w nmap S ;b Remap s and S to be easymotion forward and backward. I never use s, since it's largely…

Space is my leader key.

Same, and return is my BufExplorer. Lightning fast.

Re: Vim After 11 Years

#169

Post by thelibrarian »

jcurbo wrote: post #143
h2s wrote: post #40

Lots of people seem to declare ; or , to be useless keys and remap them. They're two of my most used movement keys in certain circumstances. I used to have , remapped to but switched back when I realised what I was missing out on. I'd advise anybody else to reconsider if they've made the same mistake I did.

I use \ for , doesn't seem to clash with anything I do on a regular basis (but I'm not a power user by any means)

It doesn't clash with anything at all, as it is the default .

Re: Vim After 11 Years

#170

Post by ethereal »

derwiki wrote: post #39

The author mentioned CtrlP for fuzzy filename matching. Its great because it's in pure Vimscript, but in my experience it becomes unusably slow for moderately sized projects. A month or two ago, I switched back to CommandT (requires Vim to be compiled with Ruby support, engine written in C) and haven't thought twice about it since then.

I've found that my impression of CtrlP's speed varies dramatically depending on the project that I'm working on. For projects such as Bochs [0] (~750 files in CtrlP), I get annoyed at the initial .5-sec wait [1], but after that it's extremely fast. I don't have a particularly fast processor, either.

I find CtrlP breaks down with large projects such as the Linux kernel. While it's fast to find the initial list of files (2 seconds or so) it's extremely slow to actually search through said list, about .5-sec per keystroke.

[0] I'm not a maintainer, I just happen to be using its wonderful instrumentation hooks in a research project.

[1] It's about half a second on my laptop, which has an SSD. This time is dramatically larger if you have a rotary drive, more like 10-20 seconds IIRC.

Post reply on HN