Hacker News Reader

Comment by 7we4cniromfce | Hacker News Reader

I have been using pathogen since I started using vim, I can recommend it. (copy paste directions to install: https://github.com/tpope/vim-pathogen) And this is where you can find vim plug-ins: http://vimawesome.com/

After installing pathogen, to install a plug-in:

cd ~/.vim/bundle

git clone <url>

and you are done in most cases, some require adding a few lines on ~/.vimrc.

There are multiple ways to work with multiple files. There are tabs in vim, split screens, files in buffer etc, these are all without plug-ins.

View on HN

> I have been using pathogen since I started using vim

Thanks for the recommendation. The trouble (and again, maybe this is down to my lack of research) is that other commenters will recommend Vundle with links to similar resources (and I've tried both Vundle and Pathogen, sometimes one after another, ruining my ~/.vim dir :P). I can find all of these recommendations myself but (maybe I'm wrong here) there's no clear winner in the vim ecosystem. There's no single de-facto manager that's used by 90% of all vimmers. Hell, I know people who I think maintain their vim plugins and config and scripts using only git, so maybe a package manager isn't even that much of a priority for many users.

> There are tabs in vim, split screens, files in buffer etc, these are all without plug-ins.

Agreed, but cursory research tells me that you have to type multiple characters to switch between files. For example, the documentation page on buffers: http://vim.wikia.com/wiki/Vim_buffer_FAQ lists about 20 different buffer navigations (bNext, bnext, bprevious etc (and why there's no bPrevious is a big fat ¯\_(ツ)_/¯ )) but not a single command for toggling between two open files, a pretty common use case. Whereas text editors like Sublime leverage the already-known (from using browsers) Ctrl + T shortcut and provide you this really necessary action in fewer keystrokes (1 vs Esc (or your Esc shortcut key) + :bNext = 7 assuming there's no shortcut for "Next" though there probably is).

> There are multiple ways to work with multiple files.

And maybe that's the problem. There are multiple ways to do everything (multiple files, plugin management etc) rather than one "best" or "recommended" way that works for most users. This is understandable for a hacker's tool; options and flags rather than intelligent defaults. But it leaves newcomers somewhat adrift. I'm not criticizing the tool itself; Bram Molenaar and co. are doing an amazing job and we should all be grateful for such a high-quality tool that's freely available on practically every nix. Something like a canonical beginner's vim config that's aggressively maintained and everyone knows about would be nice though.

EDIT: How do you type a "*"?

EDIT: Looks like switching buffers (which I think is the same as toggling between files) is :b#, which is still 4 characters vs 1. http://vim.wikia.com/wiki/VimTip686#Switching_to_the_previou...

Watch this three minute video or view the concise notes below it for some very nice tips on handling buffers.

http://vimcasts.org/episodes/working-with-buffers/

> You can quickly jump between the active buffer and the alternate buffer using the command <CTRL-^>. Pressing it again takes you back to where you were before.

If you don't like the <CTRL-^> command for this, you could map it to something else, such as the tab key, with a line in your .vimrc:

  nnoremap <TAB> <C-^>

----

> There's no single de-facto manager that's used by 90% of all vimmers.

Most recently updated plugins work with each of the managers. I use a handful of plugins with Pathogen, but the same plugins could be used with another manager.

However, the latest release of Vim now includes a built in plugin system, does that satisfy your need to have one blessed version?

https://shapeshed.com/vim-packages/

----

> 20 different buffer navigations

Keep in mind, all these commands can be shortened to the smallest unique prefix. So with `:bn` and `:bp` you can go forward and backward. But if you don't like typing three characters, just sacrifice something else by remapping it in your .vimrc!

----

> toggling between two open files, a pretty common use case

When I am working on two files at once, I'll usually put them both up at the same time. If I have "a.txt" open and I also want to work on "b.txt" I can type `:vsp b.txt" and now I have them up side-by-side. I can switch between them with whatever command I have set up to do that.

Thanks, that video was pretty good and helped me understand buffers. If you'll indulge me a bit more though, why does Vim warn you while switching out of an unsaved buffer (and make you use !) if it's still going to keep your changes when you come back?

> However, the latest release of Vim now includes a built in plugin system, does that satisfy your need to have one blessed version?

It absolutely does. I'm going to try it out!

Not sure if you'll find this delayed comment, but I can give it a shot.

There is a note on the linked video page about `set hidden`, but it doesn't spend much time explaining it. If we open Vim and type `:help hidden`, we get the following:

  'hidden' 'hid'          boolean (default off)
                        global
                        {not in Vi}
        When off a buffer is unloaded when it is abandoned.  When on a
        buffer becomes hidden when it is abandoned.  If the buffer is still
        displayed in another window, it does not become hidden, of course.
        The commands that move through the buffer list sometimes make a buffer
        hidden although the 'hidden' option is off: When the buffer is
        modified, 'autowrite' is off or writing is not possible, and the '!'
        flag was used.  See also windows.txt.
        To only make one buffer hidden use the 'bufhidden' option.
        This option is set for one command with ":hide {command}" :hide.
        WARNING: It's easy to forget that you have changes in hidden buffers.
        Think twice when using ":q!" or ":qa!".

The default state of `hidden` is off, so with that in mind, the explanation basically answers why Vim warns you about switching buffers. If you switch away, the buffer is "hidden" -- Vim keeps track of what is in it and doesn't unload it. That's probably what you expect, but can lead to loss of unsaved data if you switch away from a buffer, work on some other buffers for a while, then close Vim without coming back to the unsaved one. So by default, Vim wants you to be explicit when switching away from a buffer that will become hidden. In most cases you probably want to save it first.

Turning `hidden` on would remove the warning, you could switch away from an unsaved buffer with `:bn`.

So if you want to always work with unsaved hidden buffers floating around (view them with `:ls`!), you could add `set hidden` to your .vimrc. Alternatively, you could set up a command to automatically execute a save action every time you tried to switch away from an unsaved buffer. Notice that `autowrite` is mentioned in the help text above. Running `:help autowrite` shows:

  'autowrite' 'aw'        boolean (default off)
                        global
        Write the contents of the file, if it has been modified, on each
        :next, :rewind, :last, :first, :previous, :stop, :suspend, :tag, :!,
        :make, CTRL-] and CTRL-^ command; and when a :buffer, CTRL-O, CTRL-I,
        '{A-Z0-9}, or `{A-Z0-9} command takes one to another file.
        Note that for some commands the 'autowrite' option is not used, see
        'autowriteall' for that.

So if you added `set autowrite` to your .vimrc, instead of `set hidden`, you could avoid the warnings by automatically saving the file, rather than leaving it unsaved.

Hope this helps! One of the pain points of vim is that many of the defaults end up being somewhat unexpected choices. Many people get over that by just looking up someone's post online and copying in a bunch of settings. When you do that, you don't end up learning much about navigating vim and understanding the configuration process. You just end up with a new set of defaults that might also not quite be what you want. I try to keep my .vimrc pretty plain until I realize something could be better, then spend a moment to figure out how to do that and add it in.

Thanks again!

Reply on news.ycombinator.com