RE: Gtk tabs in emacs, new branch.

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

> > 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.
> 
> Let's compare how this is implemented in web browsers.  Typing C-b in
> Firefox opens a left-side pane that indeed looks like a 
> vertical tab bar. But it has completely different semantics than the
> real tab bar.

I don't care about "real" tab bars or "real" Firefox bookmarks. I care about
what tabs will be in Emcs.

> Clicking on a bookmark opens a web page in a new tab.  
> Clicking on a tab selects a web page in the existing tab.

So what?

> So bookmarks are not a good example what the tab bar could
> be used for.

That doesn't follow at all. Anyway, please read what I wrote.

I said that I would like to be able to use tabs for the _kinds of things_ I use
Emacs bookmarks for - whether or not bookmarks are used as an intermediary. And
I gave examples of such diverse uses, which go far beyond the usual use of Emacs
bookmarks, not to mention even further beyond what one can use Firefox bookmarks
for.

I suggested thinking about such things in the interest of keeping the
model/design for Emacs tags open, general, flexible. The idea was to foster
thinking about what tabs can do and argue for keeping their use completely
flexible and general - that is, undefined.

In particular, I suggested separating a concern for implementation and
user-interaction design (GUI) from what tabs actually _do_, that is, what you
can do with them. 

I do not want Emacs design to hard-couple user-tab interaction (the GUI) with
any particular action to be effected by a tab. I want the possibilities for the
thingies that are selected or invoked by choosing a tab to remain open and
bindable at runtime (in Lisp). I want those thingies to be anything at all: a
window configuration, a desktop, a "project", a buffer, a mail, a process
invocation, or whatever.

I want a tab to be able to invoke any function whatever.

Define the GUI, fine (and I said that I probably have next to nothing to say
about that), but please let the mapping of tab<->thingie
selected/activated/invoked be open, not predefined.

As one instance of exploiting such hoped-for openness, I would like to be able
to attach/map-to/invoke a arbitrary Lisp function. Stefan spoke of commands -
via a keymap. As another instance, I suggested being able to attach an Emacs
bookmark. (No, not a Firefox bookmark, but a chunk of Emacs-Lisp that can
represent saved state and a handler function.)

So there were two different uses/mentions of bookmarks in what I wrote: (1)
bookmarks (in bookmark+) as a model or illustration of generality, to point out
some of the many different kinds of things one might like to do by clicking a
tab, and (2) invocation of existing Emacs bookmarks as one concrete example of
attaching a thingie to a tab - that is, bookmarks as one type of attachable
thingie.

The more important point is #1, by far: tabs should be able to do pretty much
anything.

If you don't in fact design them in such a way that I can directly map bookmarks
to tabs (#2), that's not a big deal. As long as I can hook/map a tab to an
arbitrary function, I can invoke a bookmark anyway (or anything else).

So perhaps reread my mail, concentrating on #1: bookmark uses as examples of
things one might want a tab to do. And forget about #2 if it adds confusion to
the discussion.

I'm OK with a hook, a handler, a keymap,...whatever (we can get to preferences
among those later). The point is simply *not* to hard-design tabs as *only*
selectors of window configs (or of any other specific thing). Do not predefine
what tabs do.

I wrote my mail in response to Jan's proposed implementation that I understand
(perhaps incorrectly) to hard-couple tabs to window configs. I do not want Emacs
tabs to be like that. I want them to be open.

> I think in Emacs the most suitable widget for that is the speed bar.
> 
> Of course, we could allow any action for tabs by design, but 
> using them for bookmarks is a bad idea.

Allow any action by design, yes. That was precisely the point.

I used different kinds of bookmarks (in bookmark+) as examples of different
kinds of things one might want to use tabs for. They were illustrations of why
tabs can be and should be more than simply window-selectors. Apparently, the
bookmark model as illustration was not clear.

Just please make sure we can attach an arbitrary function to a tab and I'll be a
happy camper, no doubt. A keymap, such as Stefan proposed, would be OK. A
function might be better. Allowing either would be good. Allowing a function,
keymap, or bookmark would be grand, but it's not necessary.

What I do not want to see is tabs being dedicated to *only* switching among X's,
where X is any single thing such as window configs, prohibiting the use of tabs
for Y's, where a Y is not an X.

Please do not predefine what tabs can do. Capice?