RE: Gtk tabs in emacs, new branch.

[Stephen J. Turnbull]

Drew Adams writes:

 > >  > 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?
 >
 > It's not clear to me, for example, what you mean by tabs
 > (necessarily) doing the same thing to different objects.

Those are scare quotes.  I wouldn't have quoted if I was able to
*define* "do the same thing"!

Let me start with some definitions: A *tab bar* (what in my previous
post I called a "tab control") is a widget which contains several
*tabs*, and (usually) a *pane* in which some kind of content is
displayed.  (In the implementation discussed below I assume the pane
is an Emacs window, but that need not be true.)  *Tabs* are clickable
buttons, but they only appear as part of a tab bar.  Within a tab bar,
there is a distinguished *top tab*.  In cases where the tabs control a
specific pane in the display, the top tab is the one associated with
the currently visible content.  Tabs may also be ordered from left to
right (assuming a horizontal orientation to avoid overloading the word
"top").  The top tab need not be leftmost, but is always visible and
visually distinguishable (unless the user has selected a weird face).

Clicking on an individual tab will cause some action to occur, usually
reflected by a change in the appearance of the content.  It always
causes the clicked tab to become the top 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's very adequately represented visually by a toolbar.  Why do you
want to duplicate the functionality of toolbars in tab bars?

 > 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.

"All hope abandon ye who enter here."  That's a toolbar.  (But I
repeat myself.  "What I say three times is true."  Wait for it!)  If
toolbars have the restrictions that menus do (which are hardly
restrictive, actually; anything that can take a function symbol as a
value can implement arbitrary behavior), you can bet that tabs will
suffer the same restrictions.

 > 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.

Sure.  A tab bar will surely be visible to Lisp as a sequence of some
kind, and accessed by a variable.  I don't see why any of the things
you describe above will be prevented by any particular implementation
of the action invoked by a tab.

 > What I'm concerned about is having the generality of associating an
 > arbitrary handler with each tab.

That's a toolbar.  Q.E.D.

If you really really need both the visual cues provided by a tab bar,
and an arbitrary handler for each tab, then (using your alist
representation, which is probably as good as any other) you could have

(defun my-tab-handler (tab ignored-datum)    ; all tab handlers take 2 args
  (let ((name (nth 0 tab))
        (handler (nth 1 tab))
        (tab-data (nthcdr 2 tab)))
    (message "handling tab '%s'" name)
    (apply handler tab-data)))

as the handler, and the tab bar would be represented in Lisp as
something like

("This establishment serves only 17-year-old Scottish tabs." ; name/doc
 my-tab-handler
 (random)          ; random tab-bar-wide datum, not used by my-tab-handler
 ("One name"       handler-1   various data)
 ("Another name"   handler-2   some    information)
 ;; etc etc
 )

But in most cases, having tab-specific handlers is probably a bad fit
for the tab metaphor.  Use a toolbar.  If your problem with that is
that Emacs toolbars are too restrictive, then fix the restrictions.

OTOH, a typical over-simplified buffer tab bar would be handled by

(defun buffer-tab-handler (tab tab-controlled-window)
  (with-selected-window tab-controlled-window
    (switch-to-buffer (second tab))))

(defun make-buffer-tabs (how-many controlled-window)
  (let ((buffers (buffer-list))
        (tabs '(controlled-window buffer-tab-handler "buffer tab")))
    (while (and buffers (> how-many 0))
      (setq tabs (cons (list (buffer-name (car buffers)) (car buffers))
                       tabs))
      (setq how-many (1- how-many))
      (setq buffers (cdr buffers)))
    (reverse tabs)))