RE: Gtk tabs in emacs, new branch.

["Drew Adams" <drew.adams@oracle.com>]

> Because the tab metaphor involves switching a well-defined area of
> screen from one use to another..., one can trivially subsume
> all uses into "window configuration management".  But the
> implementation of changing what's seen onscreen might involve far more
> than swapping one GUI widget in in place of another, and it might not
> involve swapping GUI widgets at all (where for this purpose I consider
> Emacs windows as widgets).
> 
> In use now?  Probably not, because of the very limited imaginations of
> tab developers (or if you prefer, because of the very limited
> imaginations that tab developers attribute to their users).
> 
> But easy to implement given a flexible tab framework?  Lots of them.
> How about varying font-lock to highlight different aspects of a buffer
> using "layers" of font-lock specs controlled by tabs?  Many others
> that you might classify as "window configuration management", but
> other users might not.  I have in mind switching "projects", which
> might involve piles of behind the scenes machinery such as restoring
> undisplayed buffers in the background, querying status of VCS, etc.

`Amen' to "flexible tab framework". And Stephen gives good examples of
exploiting such generality. My message is in the same vein.

I don't really want to get into this thread much - don't have much to offer,
especially regarding implementation. I'd just suggest the following about what
tabs should be able to _do_, that is, what you should be able to do with them.

I have nothing particular to say now about the questions of where tabs are
(frame, window, subwindows, whatever), how the user interacts with them
(clicking, sorting, whatever), how they should be implemented, etc.

A different and at least equally important question is what happens when a tab
is selected/clicked: what actions are carried out? what does the tab actually do
or control? Emacs gives us the opportunity to do something much more general wrt
tabs than might exist elsewhere.

Other things being equal, we should not forego generality wrt what a tab
selection can do. We should not, for example, decide that tabs should only
switch among window configs or only among buffers or desktops or projects or...
At the least, we should allow a tab to invoke an arbitrary function. That means
at least providing a hook, a handler, or equivalent.

One model that can help guide the design is to allow (but of course not require)
a tab to be associated with an Emacs bookmark. Not just with the buffer
resulting from invoking a bookmark, but with the bookmark itself - that is, with
a particular entry in `bookmark-alist'. Again, I'm not at all suggesting that we
_limit_ tabs to bookmarks but that we allow tabs to access or map to existing
bookmarks. Thinking about bookmarks can help guide the discussion about what
tabs can/should do.

A bookmark is essentially a (persistent) named collection of info. That info
typically includes a destination, which is typically a file location and a
position within the file. But although that is typical, a bookmark need not be
associated with any destination.

A bookmark can record state of any kind (persistently), and invoking a bookmark
can restore that state, without necessarily "going to" any destination. The
state restored might be entirely invisible, for example.

Stephen's example of switching among projects, thus restoring project state, is
something that you can do using bookmarks. In my library bookmark+.el[*] for
example, there are Desktop bookmarks, Dired bookmarks that restore markings and
hidden-subdirs state, del.icio.us-style tags, and other ways to represent and
switch among things such as "projects". And more and better such could easily be
imagined. (I'm looking forward to restoring window configs once we have their
serialization.)

But jumping to a bookmark need not even restore anything. "Jumping" can do
anything you want it to. A bookmark can include a handler, which is pretty much
an arbitrary function that is invoked during "jumping". Users can easily define
their own types of bookmarks (e.g. with their own handlers). Bookmark+ offers
several examples of additional kinds of bookmarks and out-of-the-ordinary
bookmark handling, to give you an idea.

The bookmarking and bookmark-jumping mechanisms are very general and are
available for any possible kind of bookmark - which means pretty much any
(persistent) named collection of info.

Being able to have a tab represent (map to) a bookmark would be very useful,
IMO. By "represent" I mean just that a tab could have as its name a bookmark
name, and clicking (selecting) the tab would invoke ("jump" to) the bookmark.
IOW, the tab would just be a shortcut for a jump call, the same way that an
entry in the *Bookmark List* buffer (`C-x r l') is such a shortcut.

Look at it also from another point of view. In bookmark+ (for example), you can
hide or show (in the *Bookmark List*) the bookmarks that satisfy certain
properties. You can mark bookmarks and then perform operations on them (as in
Dired or Buffer Menu). You can sort the bookmarks that are visible. And so on.

I'd like to be able to do the same kinds of things with tabs: hide tabs based on
certain criteria, mark tabs, act on the marked tabs (or on all tabs), sort the
tabs in a given tab bar, etc. And that includes opening/showing a set of tabs
that satisfy some property (whether or not they were shown previously and then
hidden). For example, be able to hit a key to open/add (or close/hide) all tabs
belonging to a given project.

Whatever choices are made for implementing tabs in Emacs, I'd hope that they
could trivially be made to accommodate this suggestion (using bookmarks) - among
other uses. I mention the example of bookmarks to underline what Stephen T. and
others have said wrt letting tabs be general and not forcing them to map only to
certain things such as window configurations. Bookmarks serve as a good example,
as food for thought.

And the fact that bookmarks already offer so many possibilities of switching and
restoring state points out an important point: We need not build such
functionality into the tabs (design) themselves. We should just _allow_ tabs to
leverage other features of Emacs that provide such functionality.

It would be a mistake to try to decide the behavior of tabs - what they _do_ in
some narrow way. We should define the GUI behavior (user interaction) and design
ways to invoke Emacs functions or objects such as bookmarks, but we should not
otherwise define what tabs actually do when you click them, beyond invoking some
arbitrary (Emacs-Lisp) thingy.

In general, I suggest that we look to things like bookmarks for examples of the
kinds of things we might want to be able to do with tabs. That will help us
avoid limiting the design of Emacs tabs unnecessarily. When looking for models
on which to base our design, we should think of other thingies in Emacs (such as
bookmarks), and not just think of other uses of tabs in existing applications.

Yes, we do want to be able to do with Emacs tabs _at least_ the kinds of things
you can do with Eclipse tabs or Firefox tabs. But let's not limit our design
thinking to what you can do with tabs in other apps.

Dunno whether I was clear, and apologies for rambling a bit. The point is to
keep what tabs _do_ very general, regardless of how they're implemented or what
the user/GUI interaction will be like. And thinking of what bookmarks can do is
not a bad model for such generality. Being able to use existing bookmarks via
tabs would be one example of exploiting the generality that I hope tabs will
have.

[* http://www.emacswiki.org/emacs/BookmarkPlus]