Vim is hard, I just want to click around | Hacker News Reader

Vim is hard, I just want to click around

jeffkreeftmeijer.com

178 pointsjkreeftmeijer91 comments

I've always been a little puzzled by people who use a file-drawer or file-list or similar addon with Vim, and I now I think I know why: I'm guessing most of these people have Vim open as their One Tool, much like another programmer might have Xcode or Visual Studio open as their One Tool, and they want to get everything done in it.

At work, I usually have at least two windows open at all times: Vim full-screen on one monitor, a terminal full-screen on the other—or sometimes one terminal taking up most of the screen and another smaller terminal tailing a logfile. The Vim window gets used for editing (of course), the terminal is used for running test suites and exploring the codebase and finding and opening files in Vim. The reason I've never felt the need for a file-browser plugin in Vim is because I've always used Vim with an external file-browser. :)

If anyone's interested in opening files in an existing gvim window from the terminal, here's the script I use in Linux:

    gvim -f --remote-tab-silent "$@" &

(I believe MacVim comes with a similar 'mvim' script you can use on OS X) If you don't want files to open in tabs, change "remote-tab-silent" to "remote-silent". If you call the script and there's no existing gvim window, a new one will be created.

I do literally the exact same, I rock MacVim in fullscreen surrounded by Terminal sessions on the left and right, left for building/opening files, the right for tailing the syslog.

If only Lion supported multiple monitor full screen.. :S

If you want the "old" MacVim fullscreen mode back (which supports multiple monitor full screen), just throw this into your terminal:

    defaults write org.vim.MacVim MMNativeFullScreen 0

Or even

alias vimtab="gvim -f --remote-tab-silent"

in your .bashrc, .zshrc or equivalent

The Mac OS X command open allows this directly:

  $ open -a macvim filename.ext

which permits:

  $ alias mvim="open -a macvim"

as a shortcut.

I have found issue with this recently. When I have multiple tabs open, and then attempt to open multiple files after that, it opens them all in a split view :/

    :help 'tabpagemax'

Ah, but if I set it up as an alias, I can't use it with other apps that have a configurable "Send to editor" function. :)

zsh `vimtab ~/.zshrc`

Unfortunately, the remote features require a GUI version of vim. Personally, I prefer to run vim in a tab of my terminal.

Under Linux I always run vim in a terminal. Part of this is habit because I (in the past) often edit files on remote computers and I like the consistency.

On my mac I end up using MacVim mostly so that my Vim and Terminal apps can be considered separate apps for the purpose of things like spaces, and it just seemed to integrate a little better with the Mac infrastructure.

But in general I haven't found a reason to prefer a GUI version over a terminal version when a sufficiently capable terminal is available.

The reasons I run gvim rather than terminal vim are basically all because sufficiently capable terminals do not exist:

- The excellent "solarized" colour scheme only works properly with 24-bit color unless you're willing to mess with the terminal palette and break all your other terminal apps. No terminal I know of supports 24-bit color.

- I have a handy keybinding that cycles through open windows and tabs, I find it makes the most sense bound to Ctrl-Tab and Ctrl-Shift-Tab. Neither key can be bound in any terminal I know of.

I'm using xterm with Solarized and it works pretty well. gvim is indistinguishable from vim in a terminal. I haven't observed any broken apps.

I've been using urxvt for a few years now. It supports a full color range and I adopted Solarized for a while, but went back to Tango.

I haven't had any trouble binding <ctrl>-based combinations. All my window-manager commands are based on <super>, leaving <alt> and <ctrl> open for other things. I assume <ctrl-tab> is conflicting with tab swapping in gnome-terminal or something similar.

No, it's just the way that terminals work: "Tab" is transmitted as "Ctrl-I", and there's no way to encode "Ctrl" twice in the input stream.

The remote features require a version of Vim with GUI features compiled in, but you don't have to run vim in GUI mode to use them. The only difference is that when started in console mode, Vim won't register itself as a server unless it's explicitly told to use a particular server name:

    vim --servername FOO

If you start vim in another tab with the same servername, you can open files in the first Vim, no problem:

    vim --servername FOO --remote-tab ~/.bashrc

> The remote features require a version of Vim with GUI features compiled in, but you don't have to run vim in GUI mode to use them.

You do have to have an X server available though; the client/server communication occurs via X.

Thanks that will help a lot(although I mostly use eclipse these days) but for smaller tasks having to reopen gvim with more files or opening new files can get annoying(also the lack of project/file groups checking).

I'm not a Vim user, but like you, I prefer to use several programs, which I lovingly call my disintegrated development environment.

I have a hard time watching people traditionally navigate filetrees and tabs

with emacs and ido-mode enabled I press Ctrl+X B to open a buffer, Ctrl+X F to open a file, I typically type 2 or 3 characters from the filename and emacs gives me a list of matches (with autocomplete), usually the first suggestion is correct and I press return to open the file.

I barely need to think while I do this, there is no visual clutter on my screen, and I can usually finish the before someone could take their hand from the keyboard to the mouse and move to the filetree

The (admittedly not as good) equivalent to ido-mode in vim is FuzzyFinder.

One of the biggest shortcomings of vim is the lack of a good ido-mode style file-opener. People seem to rave about command-t, although getting it set up on Windows proved too annoying for me.

FuzzyFinder is nice, but graphically it's a mess. Like everything else in vim, really.

This is the biggest meta-shortcoming of vim: the fact that it doesn't come with a built-in programming language. This forces extension authors to bring their own, with the expected consequences.

It has vimscript, but vimscript is at best emacs-lisp's inbred nephew who is just as old but huffs glue and has sex with chickens.

Actually, you can also use mzscheme, perl, python, ruby, and lua to script vim.

Indeed, but that's what the grandparent is saying—you need to bring your own language to the party.

Oddly enough, despite the title, the author of the post switched precisely to this, because the new config he found included the Cmd-T plugin, which mimics TextMate's Cmd-T functionality, which is basically what you're talking about here.

In an ideal world, ido-mode would be the standard for any kind of selecting from a list. Drives me nuts that there are still people out there writing programs that only search by prefix, or that make you actually click the mouse!

Users of Visual Studio can get something similar using the Visual Assist plugin. Works across files in the project, interesting symbols in the project, or interesting symbols in the current file. Works as well as you'd expect - or, if you don't like Visual Studio, better.

I was on the borderline between vim and emacs for a long time. I finally ended up with emacs because it handles editing multiple files and switching between them way better than vim in its default configuration. It also has a saner scripting language. Plus, I get a bunch of goodies, such as org-mode, RPN calculator and an integrated shell. Though I still start vim when I need to edit one or two files on a remote computer via ssh connection.

sublimetext has that feature also, and that's one of the key features that I love about it.

I recently wrote something very similar to Emacs' ^xf for VIM. Sadly I haven't the time to work on it as much as I would like. For those who are interested: you can grab it at https://github.com/Bogdanp/quicksilver.vim .

Reposting this for horseshoes; it seems to have been mysteriously censored.

Getting familiar with GNU screen and within vim, liberal use of :tabnew foo got me to prefer a terminal emulator for working and notes over eclipse / gedit / nautilus. (gt and gT move to different tabs and :tabm N moves the current tab to tab N btw). If from within vim you :mksession bar.vim, vim saves all your open tabs so you can :wqall and open the tabs again from the shell with vim -S bar.vim

Like seemingly everyone, I organize projects into project/doc, project/src, project/data, project/bin etc. For example, I have a start.vim each in project/doc and project/src.

Then I put lines in ~/.screenrc

  chdir /home/horseshoes/workin/myproject/doc
  screen -t myproject_doc vim -S start.vim
  chdir /home/horseshoes/workin/myproject/src
  screen -t myproject_src vim -S start.vim
  screen -t bash bash

When I start screen it automatically opens one window containing a vim sesh with all my most-looked-at documentation tabs (so I can refer to wth I was thinking and organize my mental pushdown stack a little), one window containing a sesh for the source files I currently work on, and a third window holds a shell so I can look for and alter other files or start sqlite3 or make or w/e.

The point is it fires up work for me so I just have to open a terminal and type screen and it's instantly ready compared to opening eclipse or visual studio and then navigating to the relevant related notes and documents, or cluttering up the place with a billion (or even 2 or 3) terminal emulators, since screen multiplexes them. I also like to have screen windows open with cmus (music) and a python interpreter (my calculator and preferred random 'what to make for dinner' decision maker).

I also prefer the command-line environment for programming and also most general use because of the kool tools it's full of you are no doubt very acquainted with (ls, locate, grep, less, ps, pipes et al).

(End of mysteriously censored post.)

I have no idea why this might have been censored. Maybe it's the obnoxious use of "w/e" as an abbreviation for "whatever"?

horseshoes is hellbanned for this comment: http://news.ycombinator.com/item?id=2928894

This is why I browse with dead comments enabled. A single particularly poor comment is a rather inaccurate indicator of future comment quality.

Certainly some moderation is appropriate for that comment, but I think a permanent invisiban is a bit of an overreaction to that. Does this kind of thing happen frequently?

With great frequency and very little forethought.

Yes, more so than you might think. Another showdead user.

A lot of people miss the issue of browsing through projects that you aren’t familiar with. Auto-completing/fuzzy matching takes more time than actual browsing in such a case, because you’re probably guessing half of the time. Maybe it’s just me, but I find that to be annoying within a minute.

VIM defender rushing in. I wrote a post which translates 100 Textmate features into VIM, and vice-versa. In particular, I included a section on getting used to the NERDTree.

http://www.jackkinsella.ie/2011/09/05/textmate-to-vim.html

Command-T[1] solved this 'problem' for me very nicely.

[1]: https://wincent.com/products/command-t

I agree completely about Command-T. I don't use any type of file drawer at all, I tried NerdTree and found it really annoying. The way I see it, you either know where something is already, in which case Command-T does the job, or you don't, in which case you may as well use a console, or just use :edit . in vim to open up the file & folder browser to start browsing around.

Command-T forces you to think: where is this file? And then you type in a handful of characters and retrieve it immediately. To me, that is very vim-like, because it's similar to the editing experience, where you think: what is the most efficient way to do X?

Surprised PeepOpen hasn't been mentioned yet. I use it exclusively with MacVim on OSX. It is a bit unconventional but works amazingly well: http://peepcode.com/products/peepopen

I've got this, and I find it's better than Command-T, better than Jamis Buck's now-antiquated FuzzyFinder, and even better than Textmate's own command-t functionality!

At this point, basically, if an editor doesn't support PeepOpen, I won't use that editor.

I actually used PeepOpen a lot when I was still on TextMate, but I totally forgot about it after using Command-T for a while. I'll check it out again if I run into any issues. :)

PeepOpen is the main reason I use MacVim. So excellent.

I have struggled for a while to get PeepOpen and MacVim working together. I can run :PeepOpen, and it will switch to the running peepopen application, but it doesn't load up with the project files. I've tried all sorts of .vimrc config settings that the internet has to offer, but none worked.

What's in your config for it?

I actually don't have any .vimrc config for PeepOpen. :cd into your project directory and use the shortcut (I changed my shortcut to cmd+t).

In MacVim preferences, I set "Open files from applications" to "in the current window / and set the arglist"

I too wanted to click around the first month (+/-) after switching to vim, I think we all did.

However, it seems like the author learned the basics of vim, but stopped before he learned about powerful navigation keys, visual mode etc.

I think the moral is: if you feel you don't get the hang of vim/nerdtree etc., don't give up - keep going, there is a reason why so many people use it.

That's exactly why I tried again. The drawer is just a way not to go completely mad when I'm stuck trying to open files "the fast way" and I think these tools make it easier for people to get the hang of it. :)

You can click on NERDTree with a mouse-enabled vim, for the record.

I know, I've used it for a while, but somehow it just didn't feel right, if you know what I mean. :)

Sure, I get it.

For me, vim is surprisingly similar to drinking scotch: I first tried it at age 19, and wasn't pleased with my experience at first. But a wise mentor informed me it took a little getting used to, showed me how to do it right, and after a month or two I loved it.

Here is a great post explaining some of the more intermediate stuff: http://stackoverflow.com/questions/1218390/what-is-your-most...

> don't give up

Yes. All the tutos I have read recently insist on using hjkl, which is a matter of taste, but do not emphasize what I believe is the most important (for terminal use): cut and paste.

- Easy cut and paste in Vim is done with yy and p, avoid mouse and ctrl-c/v or any other trick that is not "inside" Vim.

- Good trick are to first select a block with <shift-V>.

- Don't forget P, which is pasting above current line or before cursor, often more logical than p.

- This implies to open different files inside the same Vim instance, using :Explore or :edit

- If you have to copy some outside text inside Vim, by all means, use the paste mode (:set paste), if you don't you'll mess up your text.

Also worth remembering is that every command that deletes really cuts. Which is to say, deletion commands like x and dd store the deleted content in the register that will be used when you hit p or P. This is important to know both because it can be very useful sometimes and because it can get in your way other times (e.g., if you're trying to repeat an action and keep replacing a line with another line, you'll have to paste before you delete so you don't override your register).

Or you can specify the register name. Don't limit yourself to the unnamed register.

Absolutely. My fault for not mentioning it :)

vnoremap <leader>p "_dP

"_ is the blackhole register, with this the replaced text disappears and you can continue "putting" the new text at will.

Thanks, I didn't know about the paste mode.

The reason that people use (mac)vim is not necessarily the ‘powerful navigation keys’ etc. For me it’s the ability to deal with large files and the crazy indentation rules people use and I know it’s the same for quite some other users.

The way people work differs from person to person, the idea that someone should always just keep on trying, even if something doesn't feel right, is in my opinion useless. The real moral here is that people should accept that everybody is different and that it’s ‘ok’ for them to be different and how great it is that open-source software such as vim enables them to do so. Something that’s unfortunately always a bit harder for passionate users. (No insult intended!)

I definitely know that _I_ prefer to browse a project with a GUI that works like in the rest of my platform of choice, but I also know I’m very different from the average vim user :)

Agreed - this is pretty much the only reason MacVim lives on my machines. It handles huge files way better than anything else I've tried.

I can use vim. I know it pretty well. But the inescapable fact is that, for me, it's clunky and requires more thinking than just using a mouse and pointing at something, then typing what I want to type. I use it because I haven't found something better (and I'm sure it exists, I just haven't seen it).

It's only clunky when it isn't second nature. If you invest the time required to use it without thinking, you'll find it's quite elegant.

I can do thousands of other things with that time that are worth infinitely more to me.

As it happens, I do.

It's a text editor, not a religion.

That's your decision. But it's also why you think it's clunky.

It's an awesome text editor. Who said anything about religion?

During my undergrad time (circa 2002), I spent around 6 months using nothing but Vim. I really wanted to "grok" it.

Even after learning a lot of the commands and the different modes, it never grew on me.

I think it is a shame as I touch-type and try to minimize the use of the mouse via shortcuts.

I've been playing around with vico for a couple of days (http://vicoapp.com/) and it seems pretty nifty in terms of solving some of these from-textmate-to-vim "problems". It uses TextMate bundles and supports them reasonably well as far as I can see. It also has Cmd-T and is very much a native app rather than a wrapper around a terminal app, which is more what MacVim tends to look like (it's what I've been using for the couple of years since I switched to Mac).

There are some holes in the vi commands that I use; some of them can be filled in (I'm working on some of the ones I'm missing), some of them will probably have to wait for official work, but either way I'll probably keep using it for a few days and see how things feel at the end.

I'm working on a Gtk2 application that basically solves the same problem. It adds a sidebar with things like a file browser to a GVim editor. For getting a feel for a foreign codebase I find it much easier to use something like this than to switch between navigation/file view all the time.

I tried plugins like NERDTree, which are awesome in one way because they work everywhere vim works (like in the terminal). However, I didn't really like their feel in combination with GVim and tabs.

I created a fork of janus that removes NERDTree from the distribution just for using it with alloy's fork. Also some other nice textmate behavior like quote/brace completion is included. So to get started immediately you can use it too, it is on github: https://github.com/JFrolich/janus

Thanks, giving this a shot now.

I still click around in MacVim sometimes (mostly for navigating deep NERDtree hierarchies and for selecting text within a line).

It's all about what's going to be fastest and take the least amount of mental context switching. I didn't choose vim because it's so hard to move to the mouse occasionally, I chose it because some things are much faster/easier than in TextMate, and for some things the mouse is still faster.

Sure, from a purist point of view it's terrible, but I think vim mastery has diminishing returns at some point (granted, it's a pretty far point up the learning curve).

The author mentions trying to get around this with the nerdtree plugin. I stay away from heavy plugins like this because I think they compete with the minimalism that is so nice to the feel of vi. But I can see why you'd be attracted to it given the difficulty of dealing with multiple files.

I do this to get nice access to multiple files:

    set hidden         " allows files to be opened in background
    nmap <C-j> :bp<CR> " edit prev file with ctrl+j
    nmap <C-l> :bn<CR> " edit next file with ctrl+l

(goes in $HOME/.vimrc)

FuzzyFinder is the easiest file and buffer navigation plugin I've found. You should try it. Fuzzy matching is better than having to keep track of what files you have open and in what order.

:b completes on path.

I found FuzzyFinder slow and it interrupted my workflow.

It is slow when it has to first index your files, yeah. Path completion is not really comparable.

The times I open new file vs times :e line is already in my vim/bash history is tiny. And that tiny amount is handled fine by vim's filename completion.

There seems to be a big divide in usage between gui vim'ers who are probably doing one window/ide thing vs terminal vim'ers who probably have multiple terms/vim's open and use unix/cmd line as their die.

Note I make value judgment as to which is better (I'm sure people vary and so should their tools). My point is you should figure out which one you are and filter vim suggestions appropriately

There is nothing wrong with being more productive with a tool like TextMate instead of vim, emacs or whatever IDE or editor. You should simply use a tool that works you.

I don't get it. When I am working on a project I just go to the root project directory and open up vim. NERDTree automatically loads the file structure of the project directory which is my current focus. Why should I need a file-drawer with the unnecessary folders showing?

You don’t “should” anything. If you don’t feel the need, then don’t install it.

A bit harsh response I think. Sorry I did not get my word right. But can you explain why it is useful to you?

My response wasn't meant as harsh, it just lacked a smiley ;)

I work on a lot of OSS projects and our company does consultancy. This means I browse other’s projects on a daily basis (i.e. I don’t know the filenames yet). That, combined with the fact that I have a deep love for GUI design and platform consistency, has made me come to the conclusion that something like NERDTree wasn't working for me. I tried to keep on going for a few more weeks, but in the end I decided that writing a file browser would cost me less time than I lost during these few weeks.

I’m glad I wrote it, because now I’m perfectly happy with my MacVim setup, which I wasn't before. I’m also very glad I did not decide to revert to using TextMate or any of the other new closed source editors.

To conclude, it’s a bit of a feeling-thing. I’d invite you to try it out for a while to see if it works for or against your flow. No hard feelings either way :)

PS: It might not be apparent from the article, but the browser provides a few more functions that os x users might be used to in other apps. See the last screenshot: https://github.com/alloy/macvim/wiki/Screenshots.

I think I will give this a try. Thank you for writing this and taking the time to release it.

Browsing codebases that I am not familiar with is the exact use case for me. For navigating my own project, I do fine with MacVim + Terminal + "mvim in new tab in existing window conf" [1]. But for exploring an unfamiliar codebase, it's too cumbersome.

---[1]---

  alias mvim="open -a MacVim.app"
  In MacVim Preferences set "Open files from applications" to:

    "in the current window"
          "with a tab for each file"

Then, in Terminal you can do, "mvim file.ext" to open file.ext in a new tab in the existing MacVim window (or new if no window).

I find myself never straying very far from VIM. It keeps drawing me back. The registers, motion commands and fingers never having to leave the keyboard just work so well for me. Multiple tabs in iTerm keep me well organized and speedy.

That's a very nicely designed blog. Kudos to whoever did it, Jeff.

I've personally been thrilled with LustyExplorer

http://www.vim.org/scripts/script.php?script_id=1890

I'd say most unfavourable opinions are tied to a lack of knowledge but having powerful features ultimately doesn't negate that it's uncomfortable for some.

gVim is hard; I just want to type ctrl-v to enter blockwise Visual mode.

I normally use vim on the command line, but a lot of my coworkers use gVim on Windows. Whenever I try to help one of them out, I can't stand the fact that ctrl-v is remapped to paste by default. I recently found out how to make gVim sane again. In _vimrc, comment-out the following lines:

  behave mswin
  source $VIMRUNTIME/mswin.vim

On Windows, ctrl+q will get you the Visual Block selection.

EDIT: I think it also works on Linux... Sitting on my Windows box, at the moment, so I can't test it.

It does (both on Windows and Linux), but gVim still uses v and V for the other two Visual modes, rather than q and Q. It drives me nuts!

I'd have probably liked this when I didn't get used to Window navigation on VIM, now I want everything to work with C-W C-[HJKL].

To me the title reads "I just want to dick around", because ultimately, that's what you're doing.

yeah whole post is kind annoying, he wants to do it, but he will not, maybe he will, no he will not, like a girl. I didn't find vim that hard at all, just learn it and use it, that is all.

Reply on news.ycombinator.com