minibufexplorer is a persistent buffer manager for vim that lives in its own window. It shows all the buffers you have open, with color indicators as to which are currently visible in windows and which have unsaved changes.
It's a great plugin which I've been hooked on forever. And without the persistent buffer display I find that I now feel lost.
The problem is, minibufexpl tends to get in the way of other window controls. As it is a normal vim window, it behaves like one, causing issues if you wanted to say, rotate your other working windows. Minibufexplorer's window would rotate as well, which is obviously less than desirable.
What I really need is a plugin that persistently displays the open buffers, but doesn't behave like a window. I don't need file navigation or anything as I use other means for that. Perhaps even something like an extended status bar that was capable of displaying information on buffers like minibufexpl does?
There's a new fork of minibufexpl.vim on GitHub which aims to solve some of these problems. One of its new features is "Prevents resizing of MBE buffer by window resizing commands" and it is immune to commands such as C-WC-R (rotate windows).
https://github.com/fholgado/minibufexpl.vim
While this is not an exact answer to your question, I think you could find it useful.
FuzzyFinder plugin provides good visual representation of your open buffers,
and also offers great way to jump between them - fuzzy match.
Its list of buffers is not "persistent" meaning it's only shown on
demand, but I consider this an advantage: firstly the buffers list doesn't eat
up precious screen estate, and secondly with fuzzy match I don't feel a
need to see it at all.
Consider the below screenshot: in order to switch to ext_gcd.py I just need to press
,bg : ,b invokes buffers list and g fuzzy-matches the only buffer
whose name contains letter g.
P.S: it works with files too. My mappings are as follows:
map <leader>f :FufFileWithCurrentBufferDir **/<C-M>
map <leader>b :FufBuffer<C-M>
,f in this case recursively fuzzy-matches files starting from a directory where current buffer is placed.
Old thread, but for anyone else searching checkout the vim-airline plugin. It's very popular and has great compatibility with other plugins.
Use the g:airline#extensions#bufferline#enabled option to get what your looking for.
I really enjoy buftabs.vim because it keeps the information about which buffers I have open in the status line, which disappear when I need to type there in a nice clear manner. I find this quite preferable to minibufexplorer because my cursor never accidentally ends up in a read-only scratch buffer which takes up more space than necessary. It also does some magic-mapping of :bnext and :blast to allow hopping between buffers for a rather more "familiar" feeling.
You can use ctrlp, a plugin written in pure Vimscript and highly configurable.
:CtrlPBuffer open a window with the list of open buffers
you can begin to type, it is a fuzzy finder.
There is also Tagma Buffer Manager. I am not using it yet, but someday I will give it a try, for sure.
You can try Powerline's tabline!
I tried many plugins but they tend to take up the command line or the status line, or won't show up the whole tabs when there're too many of them.
Here is a screen shot (the top bar is the tabline!):
You need to add set showtabline=2 in .vimrc after install Powerline.
And if you want to go to the 8th buffer, :b 8 will jump to it!
Hope this helps.
Related
I am new to Vim and NERDTree, and I am trying to understand why a buffer appears as [No name] after I delete it using :bd. I want to keep my NERDTree clean so I wonder if there is a way to remove the [No name].
For example,
The l.py file is the one I am working on, and the [No name] ones are the files that I already closed (with :bd). I don't want them to show up at all because it looks messy.
Thanks!
I doubt NerdTree is putting buffers into your status line. I imagine some status line plugin like vim-airline. It would probably be best to look at your status line plugin's documentation for how to make customizations or submit an issue on the plugin's bug tracker.
We need to talk...
The biggest problem I see is that you are trying to use the status line as a makeshift "tab bar". Most other editors use a tab bar as a way to manage documents, but not Vim. This makeshift "tab bar" is probably a bad idea once you start using more files or more complicated workflows with splits or tabs (Vim's tabs are different).
Oh yeah? What about Buftabline, Airline, BufTabs, MiniBufExpl, ...?
All these plugins do is show you your currently listed buffers. Maybe with some kind of positioning information so that you feel comfortable cycling via :bnext and :bprevious (or whatever mappings you might be using) through your buffer list.
Now that is great and all, these plugins have recreated other editor's version of tabs, but Vim already let you cycle through buffers without these plugins. The only thing missing was a menu which :ls will gladly do for you without wasting any screen real-estate.
Imagine having 10, 25, 50, or 100+ buffers open. How is your Buftabline going to handle that? My bet is not well. You need to stop reaching for simple tools like :bnext / :bprev and start reaching for a power tool like :b.
Behold the power of :b
The :b command can take a buffer number to switch directly to a buffer. Far more interesting, :b can take a partial filename.
:b partial-name
Need more power in your :b?
Uses tab completion
Uses <c-d> to list out completions
Accepts globs. e.g. :b *foo
Use ** to descend into directories. e.g. :b foo/**/bar
Don't forget to add set hidden to your vimrc. See :h 'hidden'
Why ride a bike when you can fly?
taken from Bairui's collection of Vim infographics.
You can use a simple mapping to leverage both :ls and :b:
nnoremap <leader>b :ls<cr>:b<space>
Now you can travel directly to you buffer you want. No more cycling.
But I like plugins
Who doesn't like a good plugin. As a matter a fact if you are looking for a nice buffer switching plugin then I would recommend you look into a nice fuzzy finder like CtrlP to aid you in switching between buffers. A fuzzy finder actually adds value to switching between buffers by getting you there faster with less typing.
Conclusion
Eventually you workflow will require you to use more than 3 buffers at a time. At that moment I would suggest you take another look at the :b command or at the very least get a nice fuzzy finder. It will save you time and effort.
So stop riding your bike when you can fly.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I don't understand buffers. When I open 3 files on the same tab and close my window, I'm generally annoyed to find out next time I open one of those files that there are strange swap files lingering and giving me pesky messages. But time and time again I read that these things are the productivity nirvana I'm missing out on and that tabs were made for the plebeians to use.
So I ask you, the Vim expert: what are the advantages of using buffers over tabs? I don't see how the difference could be profoundly different, but I would consider myself only at the beginner-intermediate level at operating Vim. Is :ls :b# really that much faster than gting around? I feel it must go deeper than this.
As ZyX said on #vim, this question sounds like "Why do Vim experts prefer tasty over warm?".
"Vim experts" don't prefer buffers over tabs: they use buffers as the file proxies they are and tab pages as the workspaces they are. Buffers and tab pages have different purposes so preferring one to the other makes no sense whatsoever.
The issue with buffers and tabs is one of confusion, caused by a combination of independent facts.
Most "modern" text editors and IDEs use a tab metaphor to represent loaded files. That metaphor acts as an information system — it shows the user what files are opened and their state — and as an interactive device — it allows the user to manipulate (reorder, select, close…) those opened files. Despite their many limitations, tabs are everywhere and people are used to them and expect them everywhere.
Vim introduced tab pages in 7.0 as a way for its users to create ad-hoc "workspaces". Nothing in their features, their specific options, their specific commands or their :help sections suggests that tab pages could or should be used as file proxies.
Nothing except the name and the appearance of "tab pages", of course, which leads to much confusion.
Without :set hidden, which is disabled by default and not very easy to find, Vim makes it impossible to switch to another buffer without writing the current one or abandoning its changes. New users, unaware of that option, have no choice but to turn to heavy windows use or to the closest "tab-like" feature they can find: tab pages.
"Tab page" is an unfortunate name choice for that feature, especially in an era dominated by the idea that reading documentation is a waste of time.
In Vim, tab pages are an abstraction built on top of windows, themselves an abstraction built on top of buffers. Each new level adds useful features but restricts your workflow.
The "buffer way"
With a buffer-based workflow, the files you are working with are distributed along a single dimension. You can cycle through your buffers, you can access a specific buffer by typing part of its name (with completion) or its number, you can alternate between buffers, you can target them pretty easily. There's basically no friction.
Eight buffers open, only one visible:
Switching by number:
Switching by name:
Buffers are Vim's file-proxies. If you think in terms of files, you think in terms of buffers.
The "window way"
With a window-based workflow, your "files" are both distributed along the same single "virtual" dimension as they would if you only used buffers and along two other "physical" dimensions. But the cartesian spaces in which those dimensions are found are almost completely separated: moving to another buffer still means "moving to another file" but moving to another window doesn't. The buffer that corresponds to the desired file may be displayed in that window but it could also be displayed in another one, maybe in another tab page, or not at all.
With windows, navigating between open files either becomes too complex or too simplistic, even with 'switchbuf' and :sb. Mostly because you are forced to use two sets of commands for what is essentially the same thing: accessing a buffer.
Windows have their use, as described below, but they don't have what it takes to replace buffers in anybody's workflow.
Here I am working on a Vim colorscheme. The two windows are different views of the same buffer: the top one serves as reference, with a table of the color codes used in the colorscheme, and the bottom one is where I work:
Windows are not designed as file-proxies and can't be made into ones: they are "containers" or "viewports" designed to offer you a view into a buffer. No more, no less.
The "tab way"
With a tab-based workflow, you essentially try to mimic the user experience you are used to from your previous editor while completely ignoring the very nature of Vim's tab pages. If we forget for a moment that this strategy is generally very unproductive, it is also impossible, just like with windows, to force Vim to adhere to that "one file = one tab" paradigm without losing a lot of flexibility.
Still working with the same files as above, the tabline takes up a significant space for virtually no benefit. All my files and all my tabs are called javascript*.vim so I can't do 3gt and be confident I'll end up at the right place and it is impossible to reach a specific tab by name. Add to that the fact that its label can very well be the very unhelpful but perfectly logical [Quickfix List]… Since there is no practical way to tie a file/buffer to a tab page, you are basically left with only one practical way to navigate between tab pages/buffers/files: cycling.
And yeah, my tabline is clobbered with only 8 tabs, imagine if I had 20!
Eight buffers open in eight tab pages (wrong)
Two tabs for two specific tasks (right)
Tab pages are "containers" or "viewports" designed to contain one or more windows, themselves also "containers" designed to contain buffers.
In conclusion
"Vim experts" (let's assume I can speak as if I was one) don't prefer buffers over tabs: they just use Vim as it was designed and are perfectly comfortable with that design:
"Vim experts" have 2, 30 or 97 buffers loaded and are very happy they don't have to deal with spatial distribution;
when they need to compare two files or work in one part of the current buffer while keeping another as a reference, "Vim experts" use windows because that's how they are meant to be used;
when they need to work for a while on a separate part of the project without messing with their current view, "Vim experts" load a brand new tab page.
I used to keep every buffer in a separate tab, but I grew tired of constantly gt and gT-ing around everywhere.
I also felt that buffers were too difficult to manage.
Here are some techniques that totally changed my earlier opinion:
Buffer management: :b. You get surprisingly fast at this. See vim, switching between files rapidly using vanilla Vim (no plugins)
Jump/Change lists (ctrl o/i and g;)
Alternate file (^)
tpope's Unimpaired plugin. Convenient mappings for flying through your buffers (among others).
Here is my typical workflow:
Open Vim, and use :e (usually with a regex like :e src/**/F*Bar.js) to open a buffer
Realize I need to open another file. Use :e for that as well. If I want to toggle between this buffer and the currently open buffer I will use :sp or :vsp to open it in a separate window.
Repeat until I've got the 3-5 files that I will be switching between using the techniques in the above bulleted list to fly between your buffers.
If I want to "start over" with my buffers, just close Vim and re-open.
I felt that after a week or so of forcing these new patterns, it became much easier to visualize which buffers I had open, and how to get to any one of them in only a few automatic strokes.
Tosses 2c into the pile.
TLDR; :b *part-of-filename* is the best way to find a file you need in the buffer list i.e. it is FASTER and has LESS cognitive load than buffer numbers, tabs, or windows for tracking files.
It's nothing for me to have 30 buffers open (I.e. I haven't been housekeeping), and the beauty of buffers used-well is that it doesn't slow me down at all. In fact, it speeds things up when four days after I opened the file I need it, call :b *part-of-filename* and it magically appears, impressing co-workers and toady collectivists alike.
Buffers are for files.
To be effective:
Open an important first file from a devilishly well chosen root directory
Open subsequent files with :e
Use ls ALL the time when you first start to get a good mental model (you can't grok what you can't see, mentally or literally)
Never :q, it blows
Enter :b into your muscle memory
:b1 is good for the first file you know you opened, otherwise numbers and letters get clumsy quick
:b# is good for switching to your last file, which is a common need
:bd# is good for when you've switched to a temp file, done what you needed to do, switched back with :b#, and now want to close that temp file
:b *part-of-filename* is otherwise the best way to find a file you need in the list i.e. it is FASTER and has LESS cognitive load than buffer numbers, tabs, or windows for tracking files.
The only annoyance of :b *part-of-filename* is that sometimes you haven't opened the file yet, and you need to go back and :e path/to/full-filename first.
Tabs are for differentiating truly unrelated files.
Or keeping a particular windows layout handy (disclaimer: I've never used it for this myself).
Or for files rarely used, but predictably needed. For me, that's usually a commitMessage file that I annotate as I work so I don't have to do too much thinking when it comes time to make a commit. gt is faster than :b com<enter> (if you're feeling lucky, otherwise :b com<tab><enter>)
:tabe commitMessage
gt or gT also a muscle memory favorite
Window splits are for visually comparing information
Or having immediate access to important information (truthfully, unless that info is somehow something I need to live update with :e i.e. a log file, I usually just pull the content into the current file and deal with it there).
:vsp or C-w v opens a vertical split i.e. left | right, then use :b or :e to get the file you want
:sp or C-w s open a horizontal split i.e. top / bottom
C-w C-w i.e. double Ctrl-w, rotates you around the available windows
C-w c close current window
C-w o close all other windows, keep current ONLY
The downside of tabs is that you can only see the contents of one at a time. So if you use them like in a browser, you're losing out on viewing multiple buffers side by side, or even viewing separate parts of the same file in splits. Therefore, many recommend to use tabs only to segregate different workspaces (e.g. have one for a Java project, another for a todo list, a third to hack on a script on the side).
The problems you describe make it appear that you're using Vim wrong. Either have (mostly) a single, dedicated instance. Then, buffers that become hidden will simply "reappear" if you re-edit them (and you can now use the buffer list to recall them), and there won't be swap file messages. Or, use separate Vim instances per project / file / edit session, but then make it a habit to fully :quit each instance when you're done with the file.
Another tip, when using the buffer name as the argument to :buffer, you don't have to specify entire names. However, if more than one buffer matches the given argument, the buffers won't be switched.
Any fragment of the buffer name can be used to match. For example, if you have the buffers request_manager.java and queue_manager.java then :buffer que or :b que matches both of them, but will switch to queue_manager.java as it matches at the beginning.
Tabs and Buffers are two different standards in Vi.
Read these three definitions:
A buffer is the in-memory text of a file
A window is a viewport on a buffer.
A tab page is a collection of windows.
Read this article for more https://joshldavis.com/2014/04/05/vim-tab-madness-buffers-vs-tabs/
I use tabs, Ctrl-P and Vim sessions in my workflow and have for over a year now:
I have ) and ( mapped to "go to next tab" and "go to previous tab" respectively. tn opens a new tab. I also make use of tabm to help keep things organized.
I use Vim sessions for groups of files relating to the current story/bug I'm working on, usually done by category. These sessions get overwritten during the course of the process.
I have yet to find anything better than Ctrl-P, but it does take a bit to process all the files for finding.
I would like to suggest a brillent implementation from a good number of years ago: kien/tabman.vim. It clarifies the following:
One can have as many buffers that are carefully hidden, somewhere;
By design, tabs are meant to display bufferes in creative ways.
With some proper tabline plugin, one can display all the hidden buffers at the top row (tabline);
Per my experience with vim-airline, the tabline will show very few relevant information when I create a new tab.
Two tags will occupy the tabline slot, side by side, wasting the rest of the horizontal spaces
Worst still, I no longer have any idea of what are the buffers that are hidden.
It has been a wonderful rediscovery of this magic plugin, which should have been staying in my Vim configuration for a good number of years as well.
While I would continue to look for some thing that also displays all the hidden buffers, TabMan is my superman when it comes to having a bird's eye view of how buffers were arranged across different tabs.
I load "selected" buffers as tabs to quickly (TAB/S-TAB) toggle between them.
The framework of workspaces fits here as for me buffers VS tabs is mostly the visibility thing. I can pop important/work files in windows and tabs and hide the ones I don't currently need to utilize in the background on the fly without having to remember paths or take time to search and load them up again once the need arises. This allows for handling several tasks or projects in one VIM session, I guess this used to be important in low-memory machines but is also good for concentrating all editing tasks under one application frame. I also have buffer shifting shortcuts set to Ctrl-Right/Left so I can quickly shift through various buffers as well.
Bottom line, one can only split up to some windows for his uses as much as screen estate goes, but one can hold multiple windows settings in several tabs thus expanding one's workspace and improving workflow allowing the convenient division of complicated tasks revolving more than one file.
For the swap files, you can tell VIM to keep all of them in one folder of your designation. For this use :set directory.
Add these to your .vimrc and start loving buffers:
:nnoremap <Tab> :n<cr>
:nnoremap <S-Tab> :N<cr>
That way you can cycle forward/backward through them in normal mode via Tab/ShiftTab.
Am used to IDE style tab'd panels and am hitting some arggghh inducing scenarios with vim when trying to replicate this functionality using buffers and splits.
I have the following relevant .vimrc settings:
set hidden
set switchbuf=useopen,usetab
Now, let's say I open up 4 buffers, split vertically and then horizontally so that 1 buffer displays on the left and 2 buffers display stacked on the right. The 4th buffer is hidden (opened on the left split).
With the cursor in the left split, using :bnext and :bprevious rotates through all buffers in the left split; that's not desirable as I really have no use for seeing the same file contents in 2 different splits (is there a way to opt-in to the vim cloned buffer affect?). Using :sbnext and :sbprevious works great for visible buffers, but as soon as a hidden buffer is encountered then it opens up in a new split thus wreaking havoc on my layout. The problem gets worse when working with 10+ buffers.
Ideally I'd like to rotate through all buffers visible and hidden within a given split (i.e. where the buffers were opened).
Suggestions appreciated.
p.s. am trying out vim ctrl-space plugin now, quite good but does not address above issue.
Thanks
Why rotate through the buffers when you can go directly to the one you want via :buffer command?
:b foo
:b take either a buffer number or a partial filename (with globs too!). I recommend the partial filename approach. You can also use tab completion to distinguish between ambiguous partial filenames.
You can use :sbuffer (:sb for short) the same way but to open a split instead.
For more help see:
:h :b
:h :sb
The basic navigation unit is the buffer. Windows and tab pages are abstractions built on top of buffers that introduce their own good and bad idiosyncrasies and, most of the time, don't play well with traditional buffers.
You are having troubles because you are trying to apply buffer commands to a window-centered workflow.
As soon as you split your workspace in more than one window you are bound to use window commands for navigation and tab-navigation becomes your standard as soon as you use tab pages. As you noticed, not only is it hard (impossible, AFAIK) to make buffer-navigation window/tab-aware but the alternative techniques actually lack quite a bit in terms of power.
The 4th buffer is hidden (opened on the left split).
That's your first problem: that 4th buffer is hidden and thus transient. It is not opened in any window and could be displayed in any window. You can choose to display a specific buffer in a specific window but you can't really "pin" it to that window.
With the cursor in the left split, using :bnext and :bprevious rotates through all buffers in the left split; that's not desirable as I really have no use for seeing the same file contents in 2 different splits (is there a way to opt-in to the vim cloned buffer affect?).
Again, you are using buffer commands that don't care at all about windows and tab pages.
Using :sbnext and :sbprevious works great for visible buffers, but as soon as a hidden buffer is encountered then it opens up in a new split thus wreaking havoc on my layout.
Again, the wrong tool for the job.
It is possible to keep as many window-local argument lists as you have windows and use those lists with :next and :previous, though, but that would require quite a bit of focus and forethinking. Maybe there's a plugin for that? Anyway:
Create your layout:
:vs|sp
Go back to the large window on the left:
<C-w>w
Put two files in the local argument list:
:arglocal aaa.txt bbb.txt
Move to the next window, edit your local argument list and repeat:
<C-w>w
:arglocal ccc.txt ddd.txt
<C-w>w
:arglocal eee.txt fff.txt
You can now do :next and :previous to switch arguments or <C-^> to switch to the alternate file.
Note that, while you were able to "force" somehow your buffers to specific windows, you are now seriously limited in your ability to navigate around and you now have to deal with a multi-dimensional construction that's rather fragile and requires to too many braincells.
You should consider working with Vim and not against it by using straight buffers as much as possible.
I'm using vim dwm plugin, and it is working very well for my workflow. I'm used to open a lot of buffers in the same window. With this plugin I can manage all of them with easy. I'm using vim-ctrlspace plugin too, and this two plugins are wonderful working together. Well, that's it. I hope this help!
I have been using vim NerdTree for sometime now. One thought came to my mind and i am not sure if it is possible so seeking the help of experts.
Can Nerdtree show the list of open buffers say something like :NerdtreeBuffers
I know there is BufferExplorer but i dont like it for the simple fact that i have to pre-define if i want the buffer in a tab/split/vsplit
Nerdtree is awesome ... i just need one command and then from the list i can open it however i want.
No, NERDTree doesn't have any buffer list/exploration properties. I like Buffergator (GitHub) for quick buffer listing & selection. By default, it operates similarly to NERDTree, opening a left vertical split and allowing you to navigate to a buffer and hit enter to jump to it. It also supports opening buffers in vertical/horizontal splits, and other basic functionality. CtrlP is also handy. It does fuzzy find on files, but can also limit itself to open buffers.
I have looked at the ability to use tabs in Vim (with :tabe, :tabnew, etc.) as a replacement for my current practice of having many files open in the same window in hidden buffers.
I would like every distinct file that I have open to always be in its own tab. However, there are some things that get in the way of this. How do I fix these:
When commands like gf and ^] jump to a location in another file, the file opens in a new buffer in the current tab. Is there a way to have all of these sorts of commands open the file in a new tab, or switch to the existing tab with the file if it is already open?
When switching buffers I can use
:b <part of filename><tab>
and it will complete the names of files in existing buffers. <part of filename> can even be the middle of a filename instead of the beginning. Is there an equivalent for switching tabs?
Stop, stop, stop.
This is not how Vim's tabs are designed to be used. In fact, they're misnamed. A better name would be "viewport" or "layout", because that's what a tab is—it's a different layout of windows of all of your existing buffers.
Trying to beat Vim into 1 tab == 1 buffer is an exercise in futility. Vim doesn't know or care and it will not respect it on all commands—in particular, anything that uses the quickfix buffer (:make, :grep, and :helpgrep are the ones that spring to mind) will happily ignore tabs and there's nothing you can do to stop that.
Instead:
:set hidden
If you don't have this set already, then do so. It makes vim work like every other multiple-file editor on the planet. You can have edited buffers that aren't visible in a window somewhere.
Use :bn, :bp, :b #, :b name, and ctrl-6 to switch between buffers. I like ctrl-6 myself (alone it switches to the previously used buffer, or #ctrl-6 switches to buffer number #).
Use :ls to list buffers, or a plugin like MiniBufExpl or BufExplorer.
Bit late to the party here but surprised I didn't see the following in this list:
:tab sball - this opens a new tab for each open buffer.
:help switchbuf - this controls buffer switching behaviour, try :set switchbuf=usetab,newtab. This should mean switching to the existing tab if the buffer is open, or creating a new one if not.
Vim :help window explains the confusion "tabs vs buffers" pretty well.
A buffer is the in-memory text of a file.
A window is a viewport
on a buffer.
A tab page is a collection of windows.
Opening multiple files is achieved in vim with buffers. In other editors (e.g. notepad++) this is done with tabs, so the name tab in vim maybe misleading.
Windows are for the purpose of splitting the workspace and displaying multiple files (buffers) together on one screen. In other editors this could be achieved by opening multiple GUI windows and rearranging them on the desktop.
Finally in this analogy vim's tab pages would correspond to multiple desktops, that is different rearrangements of windows.
As vim help: tab-page explains a tab page can be used, when one wants to temporarily edit a file, but does not want to change anything in the current layout of windows and buffers. In such a case another tab page can be used just for the purpose of editing that particular file.
Of course you have to remember that displaying the same file in many tab pages or windows would result in displaying the same working copy (buffer).
Contrary to some of the other answers here, I say that you can use tabs however you want. vim was designed to be versatile and customizable, rather than forcing you to work according to predefined parameters. We all know how us programmers love to impose our "ethics" on everyone else, so this achievement is certainly a primary feature.
<C-w>gf is the tab equivalent of buffers' gf command. <C-PageUp> and <C-PageDown> will switch between tabs. (In Byobu, these two commands never work for me, but they work outside of Byobu/tmux. Alternatives are gt and gT.) <C-w>T will move the current window to a new tab page.
If you'd prefer that vim use an existing tab if possible, rather than creating a duplicate tab, add :set switchbuf=usetab to your .vimrc file. You can add newtab to the list (:set switchbuf=usetab,newtab) to force QuickFix commands that display compile errors to open in separate tabs. I prefer split instead, which opens the compile errors in a split window.
If you have mouse support enabled with :set mouse=a, you can interact with the tabs by clicking on them. There's also a + button by default that will create a new tab.
For the documentation on tabs, type :help tab-page in normal mode. (After you do that, you can practice moving a window to a tab using <C-w>T.) There's a long list of commands. Some of the window commands have to do with tabs, so you might want to look at that documentation as well via :help windows.
Addition: 2013-12-19
To open multiple files in vim with each file in a separate tab, use vim -p file1 file2 .... If you're like me and always forget to add -p, you can add it at the end, as vim follows the normal command line option parsing rules. Alternatively, you can add a bash alias mapping vim to vim -p.
I ran into the same problem. I wanted tabs to work like buffers and I never quite manage to get them to. The solution that I finally settled on was to make buffers behave like tabs!
Check out the plugin called Mini Buffer Explorer, once installed and configured, you'll be able to work with buffers virtaully the same way as tabs without losing any functionality.
This is an answer for those not familiar with Vim and coming from other text editors (in my case Sublime Text).
I read through all these answers and it still wasn't clear. If you read through them enough things begin to make sense, but it took me hours of going back and forth between questions.
The first thing is, as others have explained:
Tab Pages, sound a lot like tabs, they act like tabs and look a lot like tabs in most other GUI editors, but they're not. I think it's an a bad mental model that was built on in Vim, which unfortunately clouds the extra power that you have within a tab page.
The first description that I understood was from #crenate's answer is that they are the equivalent to multiple desktops. When seen in that regard you'd only ever have a couple of desktops open but have lots of GUI windows open within each one.
I would say they are similar to in other editors/browsers:
Tab groupings
Sublime Text workspaces (i.e. a list of the open files that you have in a project)
When you see them like that you realise the power of them that you can easily group sets of files (buffers) together e.g. your CSS files, your HTML files and your JS files in different tab pages. Which is actually pretty awesome.
Other descriptions that I find confusing
Viewport
This makes no sense to me. A viewport which although it does have a defined dictionary term, I've only heard referring to Vim windows in the :help window doc. Viewport is not a term I've ever heard with regards to editors like Sublime Text, Visual Studio, Atom, Notepad++. In fact I'd never heard about it for Vim until I started to try using tab pages.
If you view tab pages like multiple desktops, then referring to a desktop as a single window seems odd.
Workspaces
This possibly makes more sense, the dictionary definition is:
A memory storage facility for temporary use.
So it's like a place where you store a group of buffers.
I didn't initially sound like Sublime Text's concept of a workspace which is a list of all the files that you have open in your project:
the sublime-workspace file, which contains user specific data, such as the open files and the modifications to each.
However thinking about it more, this does actually agree. If you regard a Vim tab page like a Sublime Text project, then it would seem odd to have just one file open in each project and keep switching between projects. Hence why using a tab page to have open only one file is odd.
Collection of windows
The :help window refers to tab pages this way. Plus numerous other answers use the same concept. However until you get your head around what a vim window is, then that's not much use, like building a castle on sand.
As I referred to above, a vim window is the same as a viewport and quiet excellently explained in this linux.com article:
A really useful feature in Vim is the ability to split the viewable area between one or more files, or just to split the window to view two bits of the same file more easily. The Vim documentation refers to this as a viewport or window, interchangeably.
You may already be familiar with this feature if you've ever used Vim's help feature by using :help topic or pressing the F1 key. When you enter help, Vim splits the viewport and opens the help documentation in the top viewport, leaving your document open in the bottom viewport.
I find it odd that a tab page is referred to as a collection of windows instead of a collection of buffers. But I guess you can have two separate tab pages open each with multiple windows all pointing at the same buffer, at least that's what I understand so far.
You can map commands that normally manipulate buffers to manipulate tabs, as I've done with gf in my .vimrc:
map gf :tabe <cfile><CR>
I'm sure you can do the same with [^
I don't think vim supports this for tabs (yet). I use gt and gT to move to the next and previous tabs, respectively. You can also use Ngt, where N is the tab number. One peeve I have is that, by default, the tab number is not displayed in the tab line. To fix this, I put a couple functions at the end of my .vimrc file (I didn't paste here because it's long and didn't format correctly).
I use buffers like tabs, using the BufExplorer plugin and a few macros:
" CTRL+b opens the buffer list
map <C-b> <esc>:BufExplorer<cr>
" gz in command mode closes the current buffer
map gz :bdelete<cr>
" g[bB] in command mode switch to the next/prev. buffer
map gb :bnext<cr>
map gB :bprev<cr>
With BufExplorer you don't have a tab bar at the top, but on the other hand it saves space on your screen, plus you can have an infinite number of files/buffers open and the buffer list is searchable...
Looking at
:help tabs
it doesn't look like vim wants to work the way you do...
Buffers are shared across tabs, so it doesn't seem possible to lock a given buffer to appear only on a certain tab.
It's a good idea, though.
You could probably get the effect you want by using a terminal that supports tabs, like multi-gnome-terminal, then running vim instances in each terminal tab. Not perfect, though...
If you want buffers to work like tabs, check out the tabline plugin.
That uses a single window, and adds a line on the top to simulate the tabs (just showing the list of buffers). This came out a long time ago when tabs were only supported in GVim but not in the command line vim. Since it is only operating with buffers, everything integrates well with the rest of vim.
relevant:
Vim: can global marks switch tabs instead of the file in the current tab?
maybe useful to solve a little part of OP's problem:
nno \ <Cmd>call To_global_mark()<cr>
fun! To_global_mark()
-tab drop /tmp/useless.md
exe 'normal! `' .. toupper(input("To global mark: "))
endf