Live data from Hacker News

Coming Home to Vim

stevelosh.com

101–110 of 125 posts

Re: Coming Home to Vim

#101

Earlier quoted context omitted.

...and once your fingers are raw, bloody stumps from typing with three modifier keys held down, then you can write about coming home to vim again! Bonus! Seriously, can we not start yet another Emacs vs. vi argument? Neither is perfect, they both have ardent fans, pick either, get really proficient with it, and don't look back. (Emacs user who loves Emacs's extensibility and multi-buffer design but prefers vi's modal…

Have you noticed that all of the recent press seems to be for vim? It seems like every month there's a new "I switched to vim!" post, but never a similar emacs version, or even a mention of emacs in the switch article. Note: I am not attempting to argue emacs vs. vim.

If I'm not mistaken, they're usually switching to vim specifically from textmate. The Mac + Ruby community seems to be disproportionately well-represented in blogs, probably due to a high concentration of web developers.

Some high-profile Ruby people (e.g. Yehuda Katz) wrote about switching to vim about two months ago (http://yehudakatz.com/2010/07/29/everyone-who-tried-to-convi...), and it probably set off a chain reaction.

Re: Coming Home to Vim

#102

Earlier quoted context omitted.

If you say why Gedit was faster perhaps us vim fanatics can help you understand us.

Let's say I need to change a word. With Gedit, I double-click the word and retype it the right way. 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. Triple-clicking in Gedit highlights a line. Triple-clicking and dragging highlights a contiguous g…

No, you would type xxg, where xx is the line number, then move with w if the word was a short distance away, or use the mouse if it was somewhere like the middle of the line, then cw. This works out favorably even a Thinkpad where I don't need to take my hands away from the home row for, and it works better when working with very large screens.

Re: Coming Home to Vim

#103
post #71

What annoys me about a lot of tech blog posts like this one is that they're essentially voodoo. People like the author write instructions about what you should do without even understanding the instructions themselves. "I’m not entirely sure what the filetype lines do. I’ve read that they’re necessary and so far I haven’t had problems." His example .vimrc has filetype listed twice, which is redundant. This in itself…

Actually I remember why I do this now. It's to make Pathogen work.

From Pathogen's docs:

    Note that you need to invoke the pathogen functions before
    invoking "filetype plugin indent on" if you want it to load
    ftdetect files. On Debian (and probably other distros), the
    system vimrc does this early on, so you actually need to
    "filetype off" before "filetype plugin indent on" to force
    reloading.
So yeah, it's not voodoo, it's not redundant, it has a purpose that I just couldn't remember off the top of my head. I'm not sure how the calls to Pathogen got moved out from between those line -- probably when I was rearranging my vimrc at some point.

Re: Coming Home to Vim

#104
post #2

One of the things I love about Vim is that every time I read though a post like this or look at someone's .vimrc I learn something new about what it can do or get another insight about how its features can make my life easier. My (semi-commented) .vimrc is on GitHub if anyone wants another example: http://github.com/samdk/vimconf/blob/master/dotvimrc I've also found StackOverflow's list of most-voted questions tagged…

That's exactly what I hate about both Emacs and Vim: yes, they are customizable, however many useful customization are scattered around user scripts.

EDIT: A flag here and there does not make a structured environment. That's why many people are running to other editors: they find that what they are more likely to need is already there in a designed way, not in a thrown-together one.

Re: Coming Home to Vim

#106
post #95
post #79

Earlier quoted context omitted.

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.

: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?

Re: Coming Home to Vim

#107
post #79

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.

:e f.b or similar from command line often using history. After using a code base for a few hours/days I pretty much know where everything is and exactly how many chars I need to type before tab autocompletes.

After I open a file once it is in my vim and or bash history which means opening it again is only a couple keystrokes.

I use 6 and multiple (3-4) non-overlapping terminals (with text mode vim) in various directories. So "jump to file foo.bar" is often look at the vim/terminal to the upper right or 6 or :ef

Don't remember what this does excactly but it's in my vimrc and might have something to do with it.

"freakin awesome file completion set wildmode=list:longest

I also use this form of "history"

bind '"\e[A"':history-search-backward bind '"\e[B"':history-search-forward

Re: Coming Home to Vim

#108
post #69

Earlier quoted context omitted.

I'm just trying to get what I think is a useful application into the hands of the people who would find it useful. If you find that irritating, just keep scrolling by.

Try contributing to discussions instead of copy-pasting the same promotional tagline. You could also make some effort to actually understand vi — your app doesn't take you out of insert mode! Using hjkl and ypu does not somehow make anything vi-like when there's no command mode, no compositionality, and a hotkey that breaks everything else. Seriously, chording‽ If you're going to chord for movement just use the built…

I'm sorry you don't find ViKing useful. It's not meant to replace vi, it's simply meant to be a tool that vi users might find useful. I know many who do.

I assure you I do understand vi. I use it everyday. I've explored the idea of making ViKing modal but based on user feedback have decided not to go that route. I am aware of the InputManagers you mentioned but I believe I'm solving a different problem.

Thank you for your feedback, though. I do appreciate it.

God bless.

Re: Coming Home to Vim

#109
post #5

Earlier quoted context omitted.

syntax on filetype on filetype plugin on filetype indent on You do not want "filetype off" Also, check out snipMate as it gives you easy to use TextMate type snippets. In Vim: :h filetype

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.

Re: Coming Home to Vim

#110
Since the blog isn't taking comments, posting it here.

> doesn't work very well with is Python, because it preserves whitespace when it moves the code over the REPL.

If that's the only issue, it's easy to fix it. All you need to do is to replace multiple new lines with single new line.

    let s:foo_text = substitute(a:text, '\n\s*\n\+', '\n', 'g') . "\n" 
Here is my slightly modified slime.vim: http://gist.github.com/589934

I have been using it on Ubuntu with vim and IPython and it seems to work fine. When I started using slime.vim for Python, I ran into whitespace issue and Jonathan(slime.vim developer) resolved it when I asked him on his blog. http://technotales.wordpress.com/2007/10/03/like-slime-for-v...

You can search for Rahul in the comments.

Post reply on HN