Vim: Buffers, Windows, and Tabs | Hacker News Reader

Vim: Buffers, Windows, and Tabs

blog.sanctum.geek.nz

207 pointspooriaazimi78 comments

I'm disappointed by how much hate there is for plugin-less vim.

The rest of us get along fine (and have for many years thanks) without your new-fangled hoos-its, or even old-fangled hoo-zits. Chirping about how useless vim is without your nerdsboggler jim-crickey is a little... yeccch.

The author of the article is right when he notes elsewhere in this thread that one should learn vim from the ground up. If one does so, one may just find not much climbing is required to get pretty damned high.

My 15 year old vimrc file has 52 lines.

Now i'm going to pop my monocle and ear-horn back in and get back to what I was doing.

Just wait until someone names a whizbang plugin "nerdsboggler-jimcrickey.vim" out of sheer spite!

Nowadays I do load a few plugins myself on the machines where I do a lot of coding or writing, but the only one that's useful every single day without fail is Tim Pope's Surround [1]. It's so useful so often that I've often thought Bram should simply ask to make it part of Vim's core to supplement the very cool idea of text objects [2]. Even if you're a crotchety old raw-Vim man, I really would say that you've got to try this out.

There are other very good plugins out there. Fugitive [3], also by Tim Pope, comes to mind if you do a lot of Git work and care about crafting really nice commits.

[1]: https://github.com/tpope/vim-surround

[2]: http://vimdoc.sourceforge.net/htmldoc/motion.html

[3]: https://github.com/tpope/vim-fugitive

I agree with you, and my Vim setup is loaded with plugins.

The power of Vim is, first and foremost, Vim. A good set of plugins is simply for augmenting Vim and/or tailoring it to your desired workflow.

The plugins I use could be broken up into groups. The first group are the ones that add truly valuable core functionality to Vim. This is the smallest group of plugins by far. I consider the "fuzzy finder" plugins to be in this group (Command-T is the one I use). These plugins add meaningful, widely-applicable functionality to the editor.

Then, there are the ones that are convenience plugins. An example is ack-vim. It lets me run ack from within Vim, and provides the ability to jump directly to files in the result list. I am, of course, perfectly capable of running ack in my terminal. But this makes using ack slightly more convenient.

Next are purely aesthetic ones, like colorschemes. Not important, but pleasant.

Finally, there are the updated language configurations - the things that provide language-specific syntax highlighting, indention, and so on. Vim already comes bundled with these. Adding them as plugins simply allows you to pull the very latest versions of them. Nice to keep these up-to-date, but unless your Vim build is old, you'll already have pretty recent versions of these.

I would miss these plugins if I could never use them again, but when I use a different editor, I rarely find myself missing plugins, but I find myself missing core Vim very badly.

You don't have to use plugins if they don't do anything you need. Conversely, there is no reason not to use plugins if they do useful things for you. There is no productivity to be gained from simply refusing to use any plugins.

vim's customizability is one of its strongest assets, I have to question the frequently occurring meme that it is somehow unsafe or questionable to actually use it.

Quote: they might end up spending a lot of fruitless time trying to force Vim to follow the same model through its configuration.

Here's a fun little snippet from my .vimrc. Enjoy ;-)

  " tab navigation like firefox
  nmap <c-s-tab> :tabprevious<cr>
  nmap <c-tab> :tabnext<cr>
  map <c-s-tab> :tabprevious<cr>
  map <c-tab> :tabnext<cr>
  imap <c-s-tab> <esc>:tabprevious<cr>i
  imap <c-tab> <esc>:tabnext<cr>i
  nmap <c-t> :tabnew<cr>:e<space>
  imap <c-t> <esc>:tabnew<cr>:e<space>

Author here. That's not quite what I meant; mapping keystrokes to Vim's tab commands is well and good, but it requires some serious kludges to make Vim behave the same way as, say, Notepad++, where one open tab equals one open file, and that's that.

"Window groups" would have been a far more accurate though potentially less familiar name for the feature, in my opinion.

I don't actually use tabs much, personally. I seldom have more than three or four files open at a time.

This not a configuration I would recommend as -

1. The mappings with TAB wont work in terminal.

2. <C-t> mapping is default map for ctags jump back.

And if you are going to be a long term Vim user, better configure Firefox like Vim than Vim like Firefox. I use Pentadectyle extension to get Vim like bindings in FF and I love it.

For switching tabs I use <c-n> and <c-p> for next/previous in command mode. Under insert mode, its default map for autocompletion which again I don't prefer remapping. Since I don't prefer to switch tabs in insert mode, that's ok.

Second Pentadactyl. There's also Vimium and Vrome for Chrome/ium. There are Vim plugins for everything these days (even Eclipse and Emacs), so that combined with a launcher like Synapse or Gnome-Do, you almost never have to use your mouse anymore.

Using Chrome and Vimium on sites like Reddit and Hacker News almost feels like cheating -- "I shouldn't be able to consume this amount of information without even having to move my wrists."

Try Pentadactyl on FF. Made me switch from Chrome to FF for regular browsing. Unfortunately Chrome's limited api makes it impossible to port Penta's robustness to Chrome.

Yes. I tried some Vim plugin for Chrome. It sucked. Pentadectyle is very robust and full-featured. Difference is considerable as compared to its Chrome counterpart. Completely transforms your FF experience.

The only thing I dislike about Vimium is it doesn't work on the "New Tab" window.

Google's cache, in case the server goes down again: http://webcache.googleusercontent.com/search?q=cache:http://...

It's strange how many people (even on HN!) don't know how to use Google's cache. You just need to type "cache:[url]" and press enter.

Thanks, I didn't know there was such an easy way to do that!

Also:

  Ctrl-w <    make vertical window narrower
  Ctrl-w >    make vertical window wider

(You can put a numeric count before the < or >)

Also:

  Ctrl-w =    make windows of equal size

And, when I want two vertical windows each of width 80:

  se co=161
  :vsplit
  Ctrl-w =

I gotta use 161 there because apparently one column is taken by the vertical separator.

Also be sure to check this guy's blog out: http://blog.sanctum.geek.nz/

Tons of other useful articles about terminal and vim and things like that...

Is there any way to use the "tabs" UI concept within one particular window? That is, for a window, have an editable list of buffers you might want to open in that window, and perhaps a tab bar at the top of that window listing those buffers. I don't like using normal Vim tabs that change between sets of windows because if I have nerdtree enabled in one tab, showing its interface in a window, that window doesn't exist in any new tabs and I have to reopen it.

There are many [1] plugins attacking the buffer switching "problem" from every possible angle. TabBar [2], for example, seems to do exactly what you are after.

My opinion is that such an "always on" list is a useless waste of place. My prefered way to switch buffers is to use CtrlP [3]. When it's not available,

    :sb <Tab>

is very nice. I've also recently added this line to my ~/.vimrc which is remarkably effective:

    nnoremap ,ls :ls<CR>:sb<Space>

[1] http://vim.wikia.com/wiki/Easier_buffer_switching#Scripts

[2] http://www.vim.org/scripts/script.php?script_id=1338

[3] http://www.vim.org/scripts/script.php?script_id=3736

I don't understand how anyone can use vanilla NERDTree because of exactly this problem. It just doesn't feel like a normal or sane editing experience when the tree keeps appearing and disappearing as you switch tabs! It's the primary reason I left Vim for an IDE at one point.

Fortunately, there's a remedy for this (which should really be default in the Janus distro). A simple plugin that makes sure NERDTree is always present and always in the same state across all tabs. https://github.com/jistr/vim-nerdtree-tabs

I found NERDTree had no advantages for me over just plain :Vex. I'm sure it does have other features, but how whizbang does a file browser need to be, anyway?

Besides, anything you want to do outside of choosing files to edit in your editor should be done in a shell: http://blog.sanctum.geek.nz/unix-as-ide-editing/

I didn't know about :Vex. At a quick glance, I'd still prefer NERDTree though, especially with nerdree-tabs as I like having a file tree and I like having one that's always present.

I do shell out a lot, but I still think it's more convenient to perform operations against nodes in NERDTree. Saves having to navigate/down/a/really/long/hierarchy.

This was very helpful. I find the constant unwillingness to link the sophistication of Emacs and Vi/Vim to the "simpler" concepts of Windows editors really frustrating, and I always appreciate it when someone extends a helping hand.

Yes, like Zork, the journey of solving Emacs or Vi with rapid keying is part of the fun, but sometimes, having a well written hint file (and yes, :help isn't it) can be really welcome.

I'm very pleased it was useful. I'm surprised to see it hit HN; I wrote it back in January and it had a lukewarm reaction on Reddit and not a peep from HN. Then again, I normally don't submit new articles to HN.

In my opinion, most of this is just replicating stuff that is better handled by a good tiling window manager.

Same goes for browser tabs. Just a kludge for the rarity of good window managers.

And most other applications that use tabs inside them.

The only problem is that when you use multiple instances of vim and let your TWM handle the tiling, you lose the sharing of registers and command/search history amongst the open buffers. I believe you can solve this by creating a vim server, but I've never tried it.

I try to keep a balance between the amount of tiling that vim and my TWM do by clumping similar parts of a project into one instance of vim. Even then I'll have the different instances of vim reside in their own WM tags. I use window splits in vim extensively and only use tabs when I'm working on small monitors (netbook) - even then I'll have at least two windows per tab.

I may have to look into this "vim server" business :D

Start GVim, it acts as a server named GVIM

    $ gvim filename

Open another file in the same GVim instance

    $ gvim --servername GVIM --remote otherfilename

can you ctrl-w-w to focus between X11 windows?

With this setup you have only one GVim instance that works as usual. Switching between this single GVim X11 window and other X11 windows from other programs is your WM's business, not Vim's.

Ah, well, I can dream.

If you're new to vim: do yourself a big favor and install Janus[1]. It installs tons of useful plugins effortlessly (literally by typing ./bootstrap.sh) and saves you hours of frustration (I'm not a fan of tweaking vimrc and installing vim plugins).

[1]: https://github.com/carlhuda/janus

If you are new to vim installing Janus or any other similar package would be the last thing to do.

Instead learn how to use bare Vim and add stuff to your ~/.vimrc and you ~/.vim/ as and when you need it.

Yes, but sane indentation, syntax coloring, soft tabs and line numbering (out of the box, without requiring you to understand how vim works and what are its configs) never hurts :)

> ... without requiring you to understand how vim works ...

That's the kicker. If you don't actually learn how Vim works, you're missing out on most of its power.

You don't need Janus, you need Vimcasts: http://vimcasts.org/

Article author here. I generally recommend against Janus because I think there's much more value in learning Vim's core behaviour thoroughly, which is best done by starting with a relatively minimal or even empty .vimrc file [1] and no plugins.

When a new user has a better command of vi basics and gets a better grasp on the actual limits of Vim's built-in behaviour, and has invested some time in crafting a configuration that suits them, personally, very well for their work and workflow they have, then they're in a much better position to select plugins judiciously and don't have to use a configuration they don't actually understand.

So far, everyone who's recommended Janus to me or asked me to write about it turned out to have a pretty poor understanding of vi-like editors in general.

For perspective, I see the oh-my-zsh [2] project much the same way. I firmly believe that it really is better to start from scratch so that you force yourself to develop an understanding of the applications you use.

Learning vanilla vi has a slightly less obvious side benefit, too -- it works everywhere. You can log into pretty much any Unix-like system and type vi, and something understandable will happen. POSIX [3] is intended to ensure that.

[1]: http://vimuniversity.com/samples/your-first-vimrc-should-be-...

[2]: https://github.com/robbyrussell/oh-my-zsh

[3]: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/vi...

I tend to agree with Yehuda Katz (a Janus co-creator) that training wheels like that which Janus offers are the best way to learn Vim. http://yehudakatz.com/2010/07/29/everyone-who-tried-to-convi...

I learned Vim the hard way because I was a student at the time, I was required to do so (or Vi at least) and I had the time to invest in it. For people learning Vim on the job, the choice is either use expedient shortcuts or go back to TextMate. Better to start this way and gradually work towards the bare metal.

I suspect the reason he was having a hard time, was because he was insisting on replicating some existing workflow structured around other tools.

If you just want to use vim as a simple editor, it doesn't seem very hard. I mean, I don't really remember a difficult learning curve.

I still only use vim that way. I let my window manager handle the complex stuff, like how to arrange windows and then how to have multiple sets of window arrangements with different things in them (i.e. tabs).

Vim only seems hard because it's so profoundly different. If you persist for even one or two evenings, I'm pretty confident most Hacker News readers are easily sharp enough to be back up to their old speed in Notepad-type editors, and from there you only get faster.

You don't have to learn it at work either. I find it's helpful to make Vim the only text editor you ever use with a dark background. The visual cue seems enough to put you in "Vim mode" so you press i before you start writing. When the background is white in your whizbang C# IDE or a Hacker News comment box, you just use your old editing habits.

My love affair with Vim started after 15 minutes in `vimtutor` when the internet went out one day. o, O, A, I, dd, p, and a couple other commands were enough for me to be see the light and be productive. Everyone needs to give vimtutor a fair shot.

I've found one of the recent updates to janus slowed down macvim significantly, so I switched to Yadr.

https://github.com/skwp/dotfiles

To be perfectly frank, I did not find this article informative, and I would not consider myself a vim expert by any stretch of the imagination. I suppose it was aimed at beginners, so maybe some people will find it helpful.

See also `:help windows-intro`.

You're right, it's not aimed at advanced or even intermediate users. To be honest I'm surprised (though flattered as I usually am) that it got onto HN. Hopefully it's useful to at least some people to clarify Vim's behaviour, since it may not be familiar to people raised on GUI editors like myself.

I found it very helpful.

I also found it useful. I'm just coming back to editors, specifically Vim, after years in IDE-land on Windows, and your simple definitions provided a nice mental model for me to build on.

"You can then flick back and forth between the tabs using :tabn and :tabp."

Also gt and gT, but I still like to map these to single-key shortcuts.

    map Y gt
    map T gT

Yes, gt and gT are the way to do this.

Admittedly I wouldn't personally recommend those mappings, because both already correspond to commands I use quite frequently. By default Y is synonym for yy, to yank a whole line, and T<char> moves back to the nearest instance of <char> on the current line. The first one I think people could live without, but the latter is kind of important for good vi.

It just might be me, but I always prefer multiple keys to pressing a dead key . After some time, my short finger cannot take it. For eg, I always use yy instead of Y.

Same here, but mine is

    nnoremap <Tab> gt
    nnoremap <S-Tab> gT

Normal mode tab switches through tabs. One (and two) key goodness.

That's a good one actually, I might switch over to that.

Unfortunately Tab is equivalent to ctrl-i, which I already use (jump forward in history list), so I can't use this in the end.

Does anybody find the vim/emacs behaviour (where buffers, windows and tabs are independent) more useful than the simpler notepad++/textmate way (one tab <-> one file/buffer)? Is there a way to force the simpler behaviour in vim?

His explanation on buffers isn't completely true, though. You can't have an unsaved non-visible buffer. Meaning, if you edit a buffer, you can't open another buffer in the same window without saving the edited one, first.

You can if you enable the 'hidden' option.

That's why so many new users turn to using tabs. Because they think they can't replace the current unsaved buffer they open another file in a tab. The result is very superficially similar to what you'd get in other editors but it is very different and full of pitfalls if you persist in treating them as regular tabs.

These two lines in your ~/.vimrc are enough to be able to work efficiently with buffers and windows and make tabs more useable:

    set hidden
    set switchbuf=useopen,usetab

The first makes it possible to replace the current unsaved buffer with another one.

The second allows you to jump to a buffer where it is (in another window, another tab) instead of replacing the current buffer with :b buffername.

Thanks! But it's too late for me - I already switched to emacs + evil-mode.

Any suggestions on getting started with emacs and evil?

To bad switchbuf doesn't actually work with :b.

Only buffer related split commands like :sbuffer, :sbnext

argh. :sb indeed.

Yup. The problem with vim is that it has way too many buttons you have to press to unbreak it.

Hmm, yes. :set hidden is recommended so often in pretty much every introductory tutorial that in places I've assumed people who have basic familiarity with Vim are already using it.

In retrospect this probably wasn't wise of me; I don't use it myself, and I still run into the occasional Vim guru online who doesn't either.

I've edited the post with a clarifying note and given you a footnote. Thanks.

He also says:

  It only goes away when you explicitly delete it with a call to :quit or :bdelete.

This isn't true. :bdelete makes the buffer an unlisted-buffer. :bwipeout actually removes the buffer completely.

http://vim.wikia.com/wiki/Vim_buffer_FAQ

Thanks for that; I clarified and gave you a footnote.

Np, it took me an embarrassingly long amount of time to grok Vims handling of Buffers, Tabs and Windows. I think your article is a nice introductory writeup on the subject. I wish I had it when I first started with Vim.

Also, as far as buffer handling goes, I really like the SelectBuf ( http://www.vim.org/scripts/script.php?script_id=107 ) plugin for listing and sorting open buffers ( including unlisted! ). CtrlP ( http://kien.github.com/ctrlp.vim/ ) works well for searching them.

not true. well, it kind of is if you don't configure your vim "right". any sensible configuration I've seen includes the "set hidden" option which will enable you to switch to another buffer w/o saving the current one. w/o this config option vim is barely usable imho.

Also the plugin "Buffer Explorer" http://www.vim.org/scripts/script.php?script_id=42 which lets you switch between all buffers easily. Without it vim is not complete.

I would recommend Buffergator instead. It has most of the same keybindings as Nerdtree (go = preview, etc.).

https://github.com/jeetsukumaran/vim-buffergator

Buffer Explorer was good for a while. I went from that, to NERD Tree, to LustyJuggler, to Command-T and LustyJuggler, to Ctrl-P and LustyJuggler.

Now I'm just using ctrl-p. It does everything for me and it doesn't require ruby or navigating file trees. I can see my MRU files, open buffers, create new files, etc., etc. all in the same area.

I'm not sure if I'm revolting against plugins, but I am attempting to remove all the extra crap I don't use but feel like I needed at some point. I recently got rid of powerline because it does nothing extra for me. It did look pretty, but that was really it.

Less is more :D

tl;dr: ctrl-p is real nice

Step one: enable dirty buffers.

no step 2. Vim will behave like any other tabbed editor. Be it using tabs or buffers. Done. Why it's not the default? Well i don't care as vim is painful in all sorts of ways without customization anyway :)

Could you expand on this? I'm not familiar with this option/setting and can't seem to turn anything up via search.

http://vim.wikia.com/wiki/Easier_buffer_switching

   :set hidden

Thanks, turns out I had it in my .vimrc already but didn't remember what it did.

Server is offline already.

So. I will just pretend i read a rant about why it all should be only buffers and tabs and windows be just presentation. And be glad someone took the time to complain about this. Was about time

it's not quite that. it's a simple tutorial on tabs, buffers, and windows, assumed at beginners.

Do you have a more advanced tutorial? I couldn't find a more comprehensive/advanced tutorial on vim tabs this morning... Everything I found were mostly about changing keyboard mappings to ease switching between tabs or thing like that.

I'm not aware of such a thing. It would really be useful as too many users think that Vim's "tabs" work the same as other editors tabs.

What kind of things would you like to know? I'm open to writing a followup.

I think a more practical one could be useful (this one was philosophical! explaining what these things are); a walkthrough, kinda like:

""press xxx to create a new tab. press xxx to switch to the new one you created. now press xxx to create a new horizontal window. press xxx to switch to it. xxx to create a vertical one...

close vi. type vi *.php to open all php files into separate buffers. press xxx to open 1.php and 2.php side-by-side...""

I could definitely do something like that. Probably not in the walkthrough style, which I don't really like, but definitely listing keystrokes and commands to use.

I'll write and post it sometime in the next week or so, if you're still interested by then. Thanks for the suggestion.

Reply on news.ycombinator.com