> > :INIT-CODE must be run to get some values that are useful for
> > :ACTIVATE-FUNCTION, :DEACTIVATE-FUNCTION, etc.
>
> Please throw away the :init-code since it's useless for the tab:
> by the time the tab is created the init-code has been run already so it
> doesn't need to be part of the tab.
>
> What is needed is a :data element.
>

I agree. It is enough to keep an ordered list of values, and you can know
that the car is the value allocated to a given object, the cadr to another
value, etc.


>
> > *** EXAMPLE1  If I want a tab that keeps a window-configuration, than we
> > need only 1 such variable: a #<window-configuration>. This is used by
> > :ACTIVATE-FUNCTION, when one switched to that tab.
>
> That window-config is the :data.  It will be passed as argument to
> the :activate-function.
>

True. You did I understand what I meant.



>  > *** EXAMPLE2 If I want to create a tab, which divides the frame in 2
> > windows: the upper window switches to buffer "xyz", and the second window
> > switches to buffer "*scratch". Then the INIT-CODE for THIS KIND OF TAB
> must
> > ask you the name of buffer1, the name of buffer2, and keep these values
> into
> > a place where these values are accessed ONLY BY :ACTIVATE-FUNCTION, and
> all
> > other functions of this tab. So the :ACTIVATE-FUNCTION of the next tab
> (that
> > probably keeps a window-configuration) MUST NOT SEE the  values kept by
> this
> > tab. The :ACTIVATE-FUNCTION of this kind of tab must do something like
>
> No difference here: the two buffers will be stored in the :data, e.g. as
> a cons cell.  So the :activate-function will simply be:
>
>   (lambda (data)
>     ( delete-other-windows )
>    (split-window-vertically)
>    (balance-windows)
>     (let ((buffer1 (car data))
>           (buffer1 (cdr data))
>     (switch-to-buffer buffer1)
>    (other-window)
>    (switch-to-buffer buffer2)
>    (other-window) )
>
> Look ma!  No get-variable mess!
>

True.


>  > Here (get-variable "buffer")) looks in tabs' environment, and finds
> exactly
> > the value it needs.
>
> Right, but luckily we neither want nor need any of that get-variable
> madness.
>

True. If you keep the variables, you need not to wonder about the order.
With variables you can keep buffer2 on the first position of :data, and
buffer2 on the second, or vice versa. Or you can conceive :data as an
obarray, as I wanted initially.


>  >> >> So it will need to change.  But does `make-tab' create a new tab or
> >> >> a tabbar?  If a tab, then I don't understand any more why the
> init-code
> >> >> is needed.
> >> > Yes, tabs must be separate from frames, and keep indepedent of every
> >> > other thing.  A frame/window can subscribe to tabs, and show them when
> >> > it is activated/etc.
> >> That doesn't answer my question: does `make-tab' create a new tab or
> >> a tabbar?
> > Your idea of (make-tab-bar PLACE) was very good. The tab bar existed
> without
> > initialization inside a frame.
>
> Not sure why you don't want to answer the question directly, but IIUC
> you're indirectly here saying that makr-tab indeed creates a tab rather
> than a tabbar.
>

For me, make-tab adds an element to the list f->tab_bar_items, and
display_tab_bar will display the :name of that element on tab-bar.



>
> OK, I think I understand how your code is expected to work.  Now can
> someone tell me how this fits in with the x-tabs and the
> gtk-tabs branches?  We need to come up with an API (at the Elisp level)
> that works for most/all of those: that doesn't means all 3 provide the
> same API, but just that we can create a common API on top of them
> without jumping through too many hoops.
>