unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Alex Schroeder <alex@emacswiki.org>
Subject: tabs proposal
Date: Wed, 19 Nov 2003 22:43:32 +0100	[thread overview]
Message-ID: <87ptfodofv.fsf_-_@emacswiki.org> (raw)
In-Reply-To: <E1AMEt4-0000Bf-Va@fencepost.gnu.org> (Richard Stallman's message of "Tue, 18 Nov 2003 18:03:58 -0500")

Richard Stallman <rms@gnu.org> 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.

Alex.
-- 
http://www.emacswiki.org/alex/
There is no substitute for experience.

  reply	other threads:[~2003-11-19 21:43 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-21  4:09 Two GTK related feature requests Simon Josefsson
2003-10-21  4:17 ` Masatake YAMATO
2003-10-21  4:27   ` Simon Josefsson
2003-10-22  9:25 ` Richard Stallman
2003-10-22 12:04   ` Simon Josefsson
2003-10-22 12:39     ` Luc Teirlinck
2003-10-22 13:44       ` Simon Josefsson
2003-11-02 19:34         ` Jan D.
2003-10-23  2:08   ` Michael Welsh Duggan
2003-10-25 20:08     ` James H.Cloos Jr.
2003-10-26  4:10       ` C-z (Re: Two GTK related feature requests) Karl Eichwalder
2003-10-26  6:11         ` Eli Zaretskii
2003-10-26  8:01           ` Karl Eichwalder
2003-10-27  7:02             ` Richard Stallman
2003-10-27 12:22               ` Kim F. Storm
2003-10-27 12:46               ` Robert J. Chassell
2003-10-27 14:05                 ` Kim F. Storm
2003-10-27 18:08                   ` Karl Eichwalder
2003-10-27 22:16                   ` Robert J. Chassell
2003-10-27 15:47                 ` C-z Werner LEMBERG
2003-10-27 16:36                 ` C-z (Re: Two GTK related feature requests) Juri Linkov
2003-10-27 19:44                   ` Kevin Rodgers
2003-10-28 20:39                 ` Richard Stallman
2003-10-29  7:01                   ` Karl Eichwalder
2003-10-29  7:28                     ` Miles Bader
2003-10-30  4:19                       ` Richard Stallman
2003-10-29  9:43                     ` David Kastrup
2003-10-29 13:30                     ` Stefan Monnier
2003-10-29 14:03                       ` Eli Zaretskii
2003-10-29 16:00                     ` Luc Teirlinck
2003-10-26 19:01         ` Stefan Monnier
2003-10-26 21:06           ` Miles Bader
2003-10-27  5:50             ` Eli Zaretskii
2003-10-27  6:46               ` Miles Bader
2003-10-27 16:55                 ` Juri Linkov
2003-10-28  2:01                   ` Miles Bader
2003-10-29 14:15           ` Stephan Stahl
2003-10-29 15:29             ` David Kastrup
2003-11-17 20:40   ` Two GTK related feature requests Kai Grossjohann
2003-11-18 23:03     ` Richard Stallman
2003-11-19 21:43       ` Alex Schroeder [this message]
2003-11-21  4:08         ` tabs proposal Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ptfodofv.fsf_-_@emacswiki.org \
    --to=alex@emacswiki.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).