Opening every buffer in its own tab

5 views
Skip to first unread message

Scara Maccai

unread,
Aug 1, 2008, 4:05:46 AM8/1/08
to vim_use
I'm trying to use Vim as any other editor I know (ultraedit, visual
studio, eclipse) when it comes to tabs, but with no success so far.

What I would like is for EVERY command that opens a buffer to

1) open a new tab if the buffer is not already open
2) switch to the buffer tab if there is already one

This is the default behaviour in all the text editors... and the most
intuitive: why would I want my tab to show another buffer when
browsing a new file (say for example I'm using ctags/cscope/a tree
file viewer...)???

I can't make it work... and apparently I'm not the only one:

http://vim.sourceforge.net/tips/tip.php?tip_id=1317

"Everyone just wants to open a tab for each buffer automatically and
have it just work. It seems fairly obvious that tabs should work this
way. It surprises me that the developers missed this."

Matt Wozniski

unread,
Aug 1, 2008, 5:11:23 AM8/1/08
to vim...@googlegroups.com
On Fri, Aug 1, 2008 at 4:05 AM, Scara Maccai wrote:
>
> I'm trying to use Vim as any other editor I know (ultraedit, visual
> studio, eclipse) when it comes to tabs, but with no success so far.
>
> What I would like is for EVERY command that opens a buffer to
>
> 1) open a new tab if the buffer is not already open
> 2) switch to the buffer tab if there is already one
>
> This is the default behaviour in all the text editors... and the most
> intuitive: why would I want my tab to show another buffer when
> browsing a new file (say for example I'm using ctags/cscope/a tree
> file viewer...)???
>
> I can't make it work... and apparently I'm not the only one:
>
> http://vim.sourceforge.net/tips/tip.php?tip_id=1317

I'd recommend not trying to use vim that way. It would severely
cripple working with multiple buffers from the possibilities vim
offers.

> "Everyone just wants to open a tab for each buffer automatically and
> have it just work. It seems fairly obvious that tabs should work this
> way. It surprises me that the developers missed this."

That's absolutely not what "everyone" wants, and most experienced
vimmers, in particular those who work with more than 30 or so buffers
simultaneously, would absolutely hate that. Tabs in vim aren't meant
to be like tabs in other editors. In most editors, in vim terms,
every tab has one window, and that one window is "stuck" to one
buffer. In vim, every tab can have any number of windows, and any
window can have any buffer displayed in it. Most editors don't even
have a way to have a buffer loaded that isn't being displayed in a
tab, I find that ability essential to my vim workflow.

I really recommend learning to use splits windows for most of your
side-by-side editing, switching the buffer displayed in a window when
switching to a different task, and only using tabs where you have a
layout of windows/buffers that you want to come back to later, so you
can start a new group of windows in a new tab. Trying to force vim to
have one buffer per window, and one window per tab, severely cripples
the options available - and frankly just isn't the work flow that vim
was designed for.

~Matt

Scara Maccai

unread,
Aug 1, 2008, 5:23:37 AM8/1/08
to vim_use
> That's absolutely not what "everyone" wants, and most experienced
> vimmers, in particular those who work with more than 30 or so buffers
> simultaneously, would absolutely hate that.  

Maybe that's what I don't understand.
How, when you have 30 buffers open, you find the buffer you want? You
can't remember all the numbers, you can't remember exactly all the
names. That's what tabs are for in other editors: find the file you
want when you remember what the name "looks like".

> Most editors don't even
> have a way to have a buffer loaded that isn't being displayed in a
> tab, I find that ability essential to my vim workflow.

Again maybe that's something I don't understand: what is a buffer good
for if you don't see it?

Please don't take these question the wrong way: I love everything
about vim, I just can't understand the "meaning" of buffers...

Thomas Geulig

unread,
Aug 1, 2008, 5:43:10 AM8/1/08
to vim...@googlegroups.com
> Maybe that's what I don't understand.
> How, when you have 30 buffers open, you find the buffer you want? You
> can't remember all the numbers, you can't remember exactly all the
> names. That's what tabs are for in other editors: find the file you
> want when you remember what the name "looks like".

And 30 tabs where the title is reduced to one letter are better?
I don't think so :-)
Sure, tooltips may show the whole filename, but working your way
through 30 tabs to find the right one isn't that fast.

> Again maybe that's something I don't understand: what is a buffer good
> for if you don't see it?

You don't see an inactive tab either (apart from (maybe) its title).

I use a mapping like this:

map __ :buffers<BAR>
\let i = input("Buffer number: ")<BAR>
\execute "buffer " . i<CR>

With two keystrokes (could even be reduced to one) I see all buffers
with names and numbers and can choose one (by name or number).
And my fingers don't leave the keyboard. Try to be faster using tabs.

> Please don't take these question the wrong way: I love everything
> about vim, I just can't understand the "meaning" of buffers...

A buffer is a buffer ;-) (I never use tabs)

Thomas

Scara Maccai

unread,
Aug 1, 2008, 6:37:49 AM8/1/08
to vim_use
> I use a mapping like this:
>
>   map __ :buffers<BAR>
>            \let i = input("Buffer number: ")<BAR>
>            \execute "buffer " . i<CR>
>
> With two keystrokes (could even be reduced to one) I see all buffers
> with names and numbers and can choose one (by name or number).
> And my fingers don't leave the keyboard. Try to be faster using tabs.

Ok, so maybe I should just stop using tabs at all.

I'll try that, thank you!

Albie Janse van Rensburg

unread,
Aug 1, 2008, 7:09:44 AM8/1/08
to vim...@googlegroups.com
Thomas Geulig wrote:
> You don't see an inactive tab either (apart from (maybe) its title).
>
> I use a mapping like this:
>
> map __ :buffers<BAR>
> \let i = input("Buffer number: ")<BAR>
> \execute "buffer " . i<CR>
>
> With two keystrokes (could even be reduced to one) I see all buffers
> with names and numbers and can choose one (by name or number).
> And my fingers don't leave the keyboard. Try to be faster using tabs.
>

Interesting map. I use tabs, but sometimes get into the situation you
described: having each tab display only a single letter.

I modified your mapping to play along with tab usage:

" See all buffers and switch to one
nnoremap __ :buffers<BAR>let i = input("Buffer number:
")<BAR>execute "execute \"tab drop \".bufname(".i.")"<CR>

I hope there's a cleaner way to do the ":drop" bit, but I just hacked it
until it would work.

--

[ Albie Janse van Rensburg ~ http://morph.telspace.co.za ]

A likely impossibility is always preferable to an unconvincing possibility.
-- Aristotle

ThoML

unread,
Aug 1, 2008, 7:19:48 AM8/1/08
to vim_use
>   map __ :buffers<BAR>
>            \let i = input("Buffer number: ")<BAR>
>            \execute "buffer " . i<CR>

:b has command line completion. So, you could use the buffer name. In
conjunction with wildmenu, this already is quite good.

I think though many user will use some sort of plugin to handle
buffers.

Benjamin Fritz

unread,
Aug 1, 2008, 8:55:00 AM8/1/08
to vim...@googlegroups.com

Here's how I use tabs, buffers, etc.

I _love_ Vim's tabs, and use them all the time. I understand that they
work differently than tabs in other applications, and really like the
difference.

I view tabs _almost_ as if they were individual instances of Vim,
except that they share access to buffers and some other things like
the quickfix window. I often have several windows open in several
tabs, often with the same buffer loaded in multiple tabs. I don't
really see any particular reason that opening a buffer should jump to
a tab if it is already open, but I believe there are plugins or tips
that accomplish that (though I can't remember what they are). I like
that I can open a file in Vim wherever I want it, whether it be in a
new window in the current tab, a new tab, etc.

Here's an example of effective use of Vim's tabs, that is impossible
in other editors:

Open a new Vim session.
:e file1.abc
:tabe file2.abc
:tabe file1.abc
:vert diffsplit file2.abc

Now, you have 1 tab that you can use to edit file1, one tab to edit
file2, and one tab dedicated to comparing differences between the two,
side-by-side.

There are many other ways to use Vim's tabs; the possibilities are
practically endless.

Note that some options can control how tabs/windows/buffers are
treated when opening files. See, for example, :help 'switchbuf'. You
can also prepend "tab" to many commands similarly to the "vert" that I
used in my example. Something I do a lot is ":tab help <topic>" so I
can see the help in it's own tab, where it doesn't reduce the working
space for my current buffer by splitting the window.

One final thing to note is that the tips on vim.org have been
superceded by the Vim Tips Wiki. The tip you reference in your post is
available at http://vim.wikia.com/wiki/VimTip1317 which has links to
two (IMO better) tab tips.

Ag. D. Hatzimanikas

unread,
Aug 1, 2008, 12:20:52 PM8/1/08
to vim...@googlegroups.com

What you describe here (in my mind) is called 'layout', which undoubtedly
is a powerful concept.

But sometimes I would like to open a tab (but) without interfering at all
with other buffers. Is that possible?

Regards,

Ag.

Ag. D. Hatzimanikas

unread,
Aug 1, 2008, 12:27:18 PM8/1/08
to vim...@googlegroups.com

To be more precise:

> But sometimes I would like to open a tab (but) without interfering at all
> with other buffers. Is that possible?

s/with/& the

but can still work with as many buffers I want, in the new tab.
In few words: Sometimes I need 'independent tabs'

> Regards,
>
> Ag.

Teemu Likonen

unread,
Aug 1, 2008, 3:07:57 PM8/1/08
to vim...@googlegroups.com
ThoML wrote (2008-08-01 04:19 -0700):

> >   map __ :buffers<BAR>
> >            \let i = input("Buffer number: ")<BAR>
> >            \execute "buffer " . i<CR>
>
> :b has command line completion. So, you could use the buffer name. In
> conjunction with wildmenu, this already is quite good.

Yes, the above mapping idea would be simpler and perhaps more powerful
this way:

:map __ :ls<CR>:b

In other words it leaves the :b command ready. Anyway, I find :ls and :b
easy and fast enough; I don't use any mappings.

Matt Wozniski

unread,
Aug 1, 2008, 3:50:27 PM8/1/08
to vim...@googlegroups.com
On Fri, Aug 1, 2008 at 5:23 AM, Scara Maccai wrote:
>
>> That's absolutely not what "everyone" wants, and most experienced
>> vimmers, in particular those who work with more than 30 or so buffers
>> simultaneously, would absolutely hate that.
>
> Maybe that's what I don't understand.
> How, when you have 30 buffers open, you find the buffer you want? You
> can't remember all the numbers, you can't remember exactly all the
> names. That's what tabs are for in other editors: find the file you
> want when you remember what the name "looks like".

As Ben Fritz says, all you need is wildmenu completion on :b <Tab>

An example, to show just how powerful this is:

:set wildmenu wildmode=full
:args vehicle.cc vehicle.h car.cc car.h jet.cc jet.h jetcar.cc jetcar.h
:b <Tab>
" ^ offers all 8 buffers as a choice
:b car<Tab>
" ^ offers car.cc and car.h
:b *car<Tab>
" ^ offers car.cc jetcar.cc car.h jetcar.h
:b .h<Tab>
" ^ offers the 4 buffers ending in .h
:b .c<Tab>
" ^ offers the 4 buffers ending in .cc
:b ar.c<Tab>
" ^ offers "car.cc" and "jetcar.cc"
:b j*c<Tab>
" ^ offers "jet.cc" "jetcar.cc" "jetcar.h"

I used to use buffer explorer plugins, until I realized I could
actually get to the buffer I was looking for faster this way 9 times
out of 10.

~Matt

Tony Mechelynck

unread,
Aug 1, 2008, 4:11:44 PM8/1/08
to vim...@googlegroups.com

In Vim, a buffer is an area of memory where Vim stores one file. A
buffer may be hidden (I rarely use that) or displayed in a window.

A window is a viewport to an area of a buffer. It consists of one
statusline (with the pathfilename of the file being edited, its line,
column, percentage down the file, the latter being replaced by "All"
"Top" or "Bot" when you are seeing one or both ends of the file) plus
zero or more lines of buffer text.

Any buffer can be displayed in any number of windows (zero or more).

Starting at version 7, one or more windows are arranged side-by-side
and/or above one another in a tab. Until Vim 6, there was no provision
for separate tabs, this is more or less equivalent to using one tab (per
instance) in version 7. At version 7 you can have one or more tabs in a
single Vim instance, which is more or less like having a choice of
preset sessions in a single instance of Vim (and therefore sharing the
same screen height, width and font).

Each tab is a distinct arrangement of one or more split windows. Unlike
windows, only one tab is displayed at a time in any Vim instance.

You can have zero, one, or more instances of Console Vim and/or gvim
running at the same time on one computer. Each instance of Console Vim
interfaces with both keyboard and display through the text terminal in
which it is loaded, and (for instance) cannot change the font; but on
Unix you don't need to start X to run it, and even on Windows you can
run it "really full-screen", with no MS-Windows frame at all (usually
80x25, 80x43 or 80x60 characters on the screen, and nothing else to
disturb you). Each instance of gvim needs a graphical interface such as
X-Windows or MS-Windows, but it can set (among others) the height, width
and font of its display interface. However, even in gvim, all tabs and
windows in a given program instance share the same font face and size.

I rarely use tabs. What I use is what I call "Rolodex Vim", which is set
as follows:

:set noequalalways winheight=99999 winminheight=0

Or sometimes I use "true split windows", either side-by-side (usually in
gvimdiff) or top-to-bottom (with ":set equalalways winheight=1").

With Rolodex Vim, all windows in the current tab are reduced to just one
statusline each, except the current window which expands to full height.
The advantage (from my POV) is that unlike with tabs (which must all fit
on a single line) here each window has one full line to display its
filename and position. Clicking on a statusbar selects that window, or I
can also use Ctrl-W w (next window down, round-robin) or Ctrl-W W (the
opposite; W is of course shift-w), or either with a count (select Nth
window). I even have the following maps to switch windows with a single key:

:map <F11> <C-W>w
:imap <F11> <C-O><C-W>w
:map <S-F11> <C-W>W
:imap <S-F11> <C-O><C-W>W

The Vim session I use most steadily (and save with ":mks!" when I want
to close gvim, e.g. to install a new version/patchlevel; then restore
later with "gvim -S") contains 15 windows (not 30) in a single tab.
Sometimes I start a parallel session in another instance, maybe with a
different font.


Best regards,
Tony.
--
Jesus was killed by a Moral Majority.

John Beckett

unread,
Aug 1, 2008, 9:48:45 PM8/1/08
to vim...@googlegroups.com
Matt Wozniski wrote:
> An example, to show just how powerful this is:
> ...

I recently tweaked a tip so I could use it in "Did you know?" on
http://vim.wikia.com/wiki/Main_Page

I recommend the tip to the OP:
http://vim.wikia.com/wiki/Vim_buffer_FAQ

While I agree about tab-completion on :bu, these two items are worth studying:
- Is there a simpler way for using the buffers under gvim (GUI Vim)?
- Is there a Vim script that simplifies using buffers with Vim?

Matt's example is very useful, so I added it as a "todo" comment at the bottom. The
tip is a little too wordy: one day I hope it will be trimmed and your example
incorporated.

John

François Ingelrest

unread,
Aug 2, 2008, 6:49:56 AM8/2/08
to vim...@googlegroups.com
On Sat, Aug 2, 2008 at 03:48, John Beckett <johnb....@gmail.com> wrote:
> I recommend the tip to the OP:
> http://vim.wikia.com/wiki/Vim_buffer_FAQ

Thanks! That's useful for me as well.

googler

unread,
Aug 2, 2008, 5:35:56 PM8/2/08
to vim_use


On Aug 1, 8:48 pm, "John Beckett" <johnb.beck...@gmail.com> wrote:
> Matt Wozniski wrote:
> > An example, to show just how powerful this is:
> > ...
>
> I recently tweaked a tip so I could use it in "Did you know?" onhttp://vim.wikia.com/wiki/Main_Page
>
> I recommend the tip to the OP:http://vim.wikia.com/wiki/Vim_buffer_FAQ
>
> While I agree about tab-completion on :bu, these two items are worth studying:
> - Is there a simpler way for using the buffers under gvim (GUI Vim)?
> - Is there a Vim script that simplifies using buffers with Vim?
>
> Matt's example is very useful, so I added it as a "todo" comment at the bottom. The
> tip is a little too wordy: one day I hope it will be trimmed and your example
> incorporated.
>
> John

This might be a very basic question, but I wanted to understand the
concept clearly. When we have several windows and tabs open in one
single vim session and if we perform a search on one of those windows,
why does it highlight the occurences of the pattern in other windows
and tabs?

Also, if I open a help topic/file using ":help", why does vim not list
that file as one of the loaded buffers when I do ":ls"?

Matt Wozniski

unread,
Aug 2, 2008, 5:58:56 PM8/2/08
to vim...@googlegroups.com
On Sat, Aug 2, 2008 at 5:35 PM, googler wrote:
>
> This might be a very basic question, but I wanted to understand the
> concept clearly. When we have several windows and tabs open in one
> single vim session and if we perform a search on one of those windows,
> why does it highlight the occurences of the pattern in other windows
> and tabs?

Because highlighting is based off a single register, and registers are
shared across all buffers. Anything that changes the '/' register
changes what is highlighted (as well as what is searched for by 'n'
and 'N'). You can prove this easily enough - after a search, when
some things are highlighted, try changing the @/ register to something
else, and the new thing will be highlighted instead, eg...
/hello world
to search for "hello world", then
:let @/="world"
to only highlight the word "world"
Then, note that pressing n and N now jump between occurrences of
"world", rather than "hello world".

> Also, if I open a help topic/file using ":help", why does vim not list
> that file as one of the loaded buffers when I do ":ls"?

Well, as it says at :help :ls, "When the [!] is included the list will
show unlisted buffers..." so, if you do ":ls!", you'll see the help
buffer show up. Help buffers are normally unlisted, because they
would generally just clutter the list, obscuring the documents that
you intended to be working on. This is why if you open a new vim
instance and do :help, then :enew a :ls will show two buffers,
numbered 1 and 3. The help buffer is at 2 (which you can confirm with
:ls!).

~Matt

Reply all
Reply to author
Forward
0 new messages