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

Coming Home to Vim

stevelosh.com

Post reply on HN
Print view View original

111–120 of 125 posts

Re: Coming Home to Vim

#111

Post by telemachos »

graywh wrote: post #109
telemachos wrote: post #98

Earlier quoted context omitted.

You do not want "filetype off" A minor quibble: you might want "filetype off" temporarily, if you use Pathogen (which the poster does). Pathogen needs to run before the filetype plugin is turned on, and due to the way some distros work (Debian and its children, primarily, I think), this requires you to start your .vimrc this way[1]: filetype off call pathogen#runtime_append_all_bundles() call pathogen#helptags() " La…

This has been changed in Debian (the system vimrc no longer turns syntax or filetype on), but persists in Ubuntu.

I wasn't aware of the change. Thanks for letting me know.

Re: Coming Home to Vim

#112

Post by xenomachina »

lenni wrote: post #106
jb55 wrote: post #95

Earlier quoted context omitted.

:b has smart tab completion. You can type any part of the filename and you can tab through the results. This is generally what I find myself doing when I have a lot of buffers open. Otherwise I just use minibufexpl with buffer next/prev keybinds.

But what about files that you haven't already opened?

:e also has tab completion.

I also use ctags. Usually I want to look things up by symbol name, not filename, though it's trivially easy to make a script that generates a tags file of just filenames too. (And :tag also supports tab completion.)

Re: Coming Home to Vim

#113

Post by stevelosh »

CGamesPlay wrote: post #53

> Some people use a mapping that turns search highlighting off and on, but I don’t like that solution. It means I have to remember to turn it back on later once I’ve probably already forgotten about the original search. :nohlsearch removes highlighting, doesn't modify search history, and also doesn't disable highlighted search. It will still highlight matches for the next search. > nnoremap S ?{ jV/^\s*\}?$ k:sort :l…

> I'm curious why not just use `ViB:sort`?

Because we use LessCSS[1] which lets you nest selectors:

    body {
        color: #151515;
        background-color: white;
        
        a {
            color: red;
        }
    }
When I sort the "body" properties I don't want it to break up the stuff nested under it.

I'll give the indent settings a try, thanks!

[1]: http://lesscss.org/

Re: Coming Home to Vim

#114

Post by stevelosh »

lenni wrote: post #79
njharman wrote: post #70

I dont see the appeal of nerdtree and the like. For me they are clumsy and too much information. I'm very adept at unix cmd line, find, ack, locate, CDPATH, cmd history, and friends. I spend 10-20% of my editing time at the bash prompt. So much so i aliased :e to vim Having never got the "gui" file managemnet tools i cant say for certain but i wonder if power and productivity gains one sees from truly learning vim ca…

Could you please share how exactly you do the "jump to file foo.bar" functionality? That is the only part of vim I still find a bit laborious, probably because I haven't found a good workflow for it.

PeepOpen or Command-T.

Re: Coming Home to Vim

#115

Post by stevelosh »

sabalaba wrote: post #105

If anybody is curious, or just wanted to steal his .vimrc (like myself), here it is [I'm surprised he didn't provide it at the end of the article...] http://paste.pocoo.org/show/265338/

Here's the BitBucket link, which will stay current as I push more updates in the future: http://bitbucket.org/sjl/dotfiles/src/tip/vim/.vimrc

I did link it in the "Important .vimrc Lines" section, but perhaps I should add it at the bottom as well.

Re: Coming Home to Vim

#116

Post by calloc »

nagnatron wrote: post #32
ollysb wrote: post #20

Earlier quoted context omitted.

Thanks! macvim here I come :) edit: Many of the most popular textmate schemes have already been converted and can be found at http://github.com/squil/vim_colors

Some are even "improved". I love molokai http://winterdom.com/2008/08/molokaiforvim .

The issue I had with Molokai (and it may be my screen) is that the comments were barely readable. The colours were just too close to the background.

My favourite is earendel (http://www.vim.org/scripts/script.php?script_id=2188)

Re: Coming Home to Vim

#117

Post by njharman » 

  "Many people like to remove any extra whitespace from the
  " ends of lines. Here is one way to do it automatically
  " when saving file.
  fun! StripTrailingWhitespaces()
    let l = line(".")
    let c = col(".")
    %s/\s\+$//e
    call cursor(l, c)
  endfun
  autocmd BufWritePre * :call StripTrailingWhitespaces()

  " When editing a file, always jump to the last known cursor position.
  au BufReadPost * if line("'\"") > 0 && line("'\"") "
    else
        return "\"
    endif
  endfunction
  " Remap the tab key to select action with InsertTabWrapper
  inoremap  =InsertTabWrapper()

Re: Coming Home to Vim

#118

Post by austintaylor »

astrofinch wrote: post #72
stevelosh wrote: post #51

Earlier quoted context omitted.

"With Vim, I press j until I'm on the line where the word is, then I press w until I'm at the beginning of the word, then I press cw to change the word, retype it the right way, and press escape to go back to command mode." OK, this is something Vim people need to work on. Using j/k to move more than one or two lines is the wrong way to do things. I know, I know, we extoll the virtues of hjkl constantly, but really t…

"There are better ways to move around in Vim, such as [f]orward, '[t]il and searching. In your case (changing word XYZ to something else) I would search for the word with /XY… and press return to get there, then edit as you described." That is both slower and has the disadvantage that any intermediary occurrences of the word between my cursor and the one I want to edit will be accessed first. "See my previous comment…

yap}p

Re: Coming Home to Vim

#119

Post by astrofinch »

Ivatar wrote: post #90
astrofinch wrote: post #72

Earlier quoted context omitted.

"There are better ways to move around in Vim, such as [f]orward, '[t]il and searching. In your case (changing word XYZ to something else) I would search for the word with /XY… and press return to get there, then edit as you described." That is both slower and has the disadvantage that any intermediary occurrences of the word between my cursor and the one I want to edit will be accessed first. "See my previous comment…

I tried your test, and was slightly faster at doing it vim than gedit (assuming my fingers were on the keyboard to begin with). How exactly did you do it in vim? I used the following: y4j5jp -- yank down to 4 lines, move down to the blank line, paste after it. I appreciate that there's an awful lot to learn before you can edit quickly in vim, and that the difference (if any) between that and gedit(or any other editor…

I did V}y}p.

Re: Coming Home to Vim

#120

Post by DennisP »

astrofinch wrote: post #74
njharman wrote: post #66

Earlier quoted context omitted.

Reading your comment it is apparent you dont now "enough" vim. It has a long learning slope with many comfortable plateaus. You must be diciplined and interested in mastering your tools to push beyound these. fyi, :set paste :set nopaste

In my Vim vs Gedit test, I was doing tasks from the beginning of the Vim tutorial using the exact commands the tutorial told me to use. It does seem possible to me that someone could become faster with Vim than a click-and-type editor, but I'd guess they'd never amortize the costs of their learning. (Of course, if you're already quite advanced then you've paid a good chunk of the cost and it may make sense to continu…

The beginning of the tutorial doesn't necessarily have the most efficient way to accomplish a task. It just has the most basic way.

For example: move up 10 lines with 10k. Move up 2 paragraphs with 2{. Move up to "what" with ?what, and if it stops somewhere else first, just hit n. Find the first letter T in a line with fT, and hit ; if you stopped at another one first. Etc. You can't put everything at the beginning of the tutorial but having a lot of these tricks in your bag speeds you up quite a bit. Then you start combining these movements with commands, repeating these combinations with just a period, recording them in macros with a couple keystrokes, applying them to every selected line with :norm, etc. It's the combination of all these things that makes it go fast.

That said, if I've got a long distance to travel and there's no obvious movement command to get me there quickly, I'll still use the mouse occasionally. It does seem to break the flow though.

The biggest improvement vim has made to my productivity isn't just the raw speed of editing, it's the fun of editing with it. That keeps me a lot more focused when the work itself gets a little mundane.

Post reply on HN