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