RE: Gtk tabs in emacs, new branch.

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

>  > I want a tab to be able to invoke any function whatever.
> 
> While perhaps sufficient generality may require that ability, remember
> that tabs as a metaphor are *not* just a contiguous row of buttons.
> They are ordered,

Yes.

> and they "do the same thing" (but to different objects).

How so?

> So I would refine "any function whatever" so that each tab control
> should have a *single* callback function, which takes maybe three
> arguments: the individual tab object itself (perhaps represented as an
> integer but better a symbol, I think, because then you could put
> properties on it), a per-tab user-defined datum (any Lisp object the
> application wants to hang on the individual tab), and perhaps another
> user-defined datum for the whole tab control.  (If you do need the
> generality of function-per-tab, you could always have the tab-control-
> wide function dispatch to per-tab functions stored in the per-tab user
> datum.  This would *remind* you that all tabs in a group "should" do
> the same thing, but it wouldn't *enforce* it.)
> 
> Either the per-tab datum or the whole-tab datum or both could be
> subsumed by properties on the tab object, I guess.
> 
> WDYT?

I'm not sure I understand all you wrote. I'm quite ignorant about much of this,
especially the how-to. My only ideas about this so far pertain to what tabs
might do and what kind of info might therefore be associated with them.

It's not clear to me, for example, what you mean by tabs (necessarily) doing the
same thing to different objects. It's also not clear why there should be a
single callback function, or what you mean by "the individual tab object" (what
is it for?) or "the whole tab control". What's the difference between the tab
and the whole tab?

Perhaps an example to illustrate, or define the terms a bit?

You click a given tab, and something happens. The tab has a name. The GUI/tab
control looks up the name to find the corresponding something-to-happen and then
effects it. Perhaps this is what you mean by "dispatch to per-tab functions
stored in the per-tab user datum" - dunno.

Yes, there is then some question about where to display things, if something
gets displayed as part of the something-to-happen. For example, if the action
involves visiting a buffer then you'd probably want that buffer to appear in a
window associated with the tab. 

I've said nothing about this display part of things. It is questions about
display that distinguish tabs from tool-bar buttons, no doubt. Yes, there is a
natural association between a tab and a window. That doesn't mean that every tab
need display exactly one window. But yes, clicking a tab typically results in
the window below it showing something that is associated with the tab.

Apart from the GUI aspects (including the display question), I see a tab bar as
an ordered sequence of named (Lisp) thingies that you can select (e.g. by
clicking). I therefore think of an alist, where the keys are the tab names and
the values are arbitrary Lisp objects.

That brings to mind an Emacs menu, where menu items are essentially alist
entries (item-name/key and command/value). Perhaps that's what Stefan had in
mind when he spoke of keymaps - dunno.

To me, it also brings to mind Emacs bookmarks, which is one reason I mentioned
them. A bookmark is just a cons (NAME . VALUE), where NAME is a string. It's
true that VALUE has an expected form to some extent for bookmarks, but really it
can be quite general. Predefined bookmark entries (in VALUE) such as `filename'
and `position' need not be mandatory. One important thing that VALUE can include
is a handler, which determines what happens when the bookmark is invoked.

Unlike the case for menus, the structure of the VALUE part of a bookmark is
quite flexible and open (e.g. to user definition), and the associated action
(handler) need not be an Emacs command (`interactive'). A default handler
applies, if none is present explicitly. To me, the bookmark model is quite
general and corresponds conceptually to a tab: a named Lisp value that can
represent some action to be performed when the tab is selected.

How a tab gets selected and what gets displayed (and how) are questions that I
haven't tried to address.

I mentioned that I would also like to be able to perform certain operations on
the tabs of a given tab bar that are similar to operations that I perform on a
list of bookmarks: (1) sort the tabs in various ways, based on both NAME and
VALUE, (2) mark the tabs and then perform operations on the marked tabs, (3)
hide certain tabs (e.g. those marked), (4) show a set of tabs that might not
already have been shown and then hidden (e.g. to "open" a project that involves
multiple tabs). And so on.

And I mentioned that (bookmark+) bookmarks can be tagged (del.icio.us-style),
which would mean that tabs would be tagged, so you could easily manipulate sets
of tabs - e.g. all the tabs that correspond to a particular project or query.

IOW, individual tabs can be selected, yes, but code (hence users) should also be
able to act on sets of tabs in various ways.

I'm thinking about tabs from a user point of view. Not just a user who clicks a
tab but also a user who might write some Lisp code to associate with a given
tab, to affect what happens when it is clicked.

Suppose, for illustration, that it would be sufficient to associate a given
existing bookmark with a given tab. The displayed tab name would be the bookmark
name. When you click the tab, the bookmark handler would be invoked, and
whatever destination is involved (if any) would be displayed (e.g. in the tab's
window).

When you invoke a bookmark normally (e.g. with `bookmark-jump') the handler is
invoked, and the handler typically includes a display function (e.g.
`pop-to-buffer'). What I envision for tabs is using the handler without its
display part. That is, suppress the display part of the bookmark handler and
substitute for it whatever display behavior we will define for tabs.

The bookmark handler would need to still visit the proper buffer (if it visits a
buffer), but not display that buffer. It is the tab code that would be in charge
of display, perhaps basing its behavior on the particular display function
defined for the handler. I haven't addressed the tab-display question, and I
probably don't have much to say about it.

What I'm concerned about is having the generality of associating an arbitrary
handler with each tab. And it would be very nice if we could leverage the
existing format of bookmarks in this regard - that is, be able to handle
existing bookmarks out of the box.