[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

tabs proposal

From: Alex Schroeder
Subject: tabs proposal
Date: Wed, 19 Nov 2003 22:43:32 +0100
User-agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux)

Richard Stallman <address@hidden> writes:

> Whether these two partial solutions are enough for real usage, I
> can't guess in advance.

I know people who do work with a gazillion tabs in several rows where
the name of the buffers or files just can't be read.  My observation
was that these people usually use tabs when there are few files and
buffers, and just ignore them when there are many.  When there are
many, they resort to other means of switching buffers or files.

An example is "tabbed browsing" in browser such as Firebird.  As soon
as I have five pages open at the same time, tabs stop being useful per
se.  So how come I sometimes have 20 tabs open?  I read a page, and
follow three links by opening them in new tabs.  Now I have four tabs
open, the system is still usable.  Then I switch to tab number two and
find five interesting pages.  I open them all in new tabs.  And from
then on the list of tabs is just a visual indication of how big my
"reading stack" is.  I just keep adding to the stack by opening new
pages in new tabs at the back, and killing tabs after I read them at
the front.

With this description on a narrative level, we can design a different
interface -- there only a max. of five tabs available.  When the user
creaates a new tab, we can add it to the end of the list, and show at
the end of the tab bar we have a tab counter for the hidden tabs
saying "1 more" (and keep increasing this as things are added).  Or if
the new tab is created due to some automatic buffer creation
(eg. Help, Apropos, etc), then we put it right after the current tab.
If we already have five tabs, the last one is removed and the tab
counter is increased.  If the current tab is tab number five, then the
new buffer would have to be invisiible.  Instead, we rotate the stack.
The first tab is moved to the end.  Now the current tab is number
four, and the new buffer is in tab number five.

It makes sense to allow "limitting" tabs to buffers by mode, age,
size, etc. -- all the stuff ibuffer does, too.

The key point is that we don't show more than a small number of tabs
at the same time.  Only the first n elements of the (possibly
filtered) buffer-list are shown.  Whenever this is not enough, we
change the order of the buffer-list such that the list of tabs shown
remains meaningful.

There is no substitute for experience.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]