Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I'm used to modeless editors. Only the past year I've been using vim/gvim, which has a modal approach.

I'm used to tabs in all editors, since before vim all of them are used to it. In gvim, you don't necessarily need to use tabs: you can just use buffers.

My question is: what are the advantages/disadvantages between these two approaches (buffers vs tabs)? Why do these both options exist?

share|improve this question

3 Answers 3

up vote 7 down vote accepted

See http://stackoverflow.com/questions/102384/using-vims-tabs-like-buffers/103590#103590 (or why spliting the vim community among all SE/SO sites is a bad idea)

share|improve this answer
1  
Agreed on the SE/SO split -- I think I prefer the 'old' way when everything was in fewer places. –  pboin Jan 5 '11 at 13:46
    
Since vim is multiplatform, indeed it's a bad idea to have posted here. I'm going to avoid it in the future. –  Somebody still uses you MS-DOS Jan 5 '11 at 18:58
1  
@Somebody and others: See this meta question. So far most respondents support vi(m) questions on this site. –  Gilles Jan 5 '11 at 19:30
    
It's not like all the people on SO/SU are aware on this topic which isn't even flagged vim. –  Luc Hermitte Jan 5 '11 at 20:49

First of all, quick naming correction - anything open in Vim is a "buffer". The terminology here is similar to emacs, if you are familiar with that editor. Buffers simply refer to open files in the memory of the current Vim process. To see a list of you buffers, use

:ls

which shows you a list of the current buffers, numbered in the order that they were opened. However, buffers do not have anything to do with the visual representation of files in Vim. I think you may be thinking of splits or views.

As to the difference between splits or tabs - It really is your preference! Some people like to be able to see a lot of code at once (or have the screen real estate to do so), and so might prefer using splits. Other people, like yourself, are more used to tabs and so might prefer that instead.

These links contain helpful information about using splits and tabs:

for splits (they call them viewports in this doc): http://www.linux.com/archive/feed/54157

for tabs: same site (sorry, can't post more than one hyperlink)

I hope this answers your question! Please clarify, if it did not.

share|improve this answer

Tabs are generally used for views and ViM tries to maintain your producitivty with plugins like BufExplorer and NERDTree for buffer management. However, I'm also guilty of using a single buffer open in each tab - it's a bad habit.

share|improve this answer
    
Almost four years later, he asks: What makes it a bad habit? –  Tony Aug 31 at 0:54
    
@Tony Because the intended use for tabs is for a layout view of your buffers. –  atx Sep 1 at 6:53
    
A single buffer in a tab is a layout view, albeit a very simple one. So I still guess I don't understand. Do you mean that if I don't split the screen within a tab, I'm exercising a bad habit? –  Tony Sep 1 at 16:57
    
@Tony It's just not the intended use for it, see the accepted answer. –  atx Sep 2 at 10:35
    
I've seen the accepted answer. But then there's this from page 80 of Practical Vim, by Drew Neil: "If we want to arrange buffers in a way that makes sense for our workflow, attempting to organize the buffer list is not the way to go. Instead, we're better off dividing our workspace using split windows, tab pages, or the argument list." (Emphasis mine.) Can you give me a specific example of how my personal habit of one buffer per tab - unless I need a split window temporarily - affects my workflow negatively, and how the use of hidden buffers instead would improve the workflow? –  Tony Sep 2 at 14:49

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.