Re: Fwd: Tabs for console.

[Stefan Monnier]

> This is a good idea, to clarify first the elisp interface.

> * TAB BAR

> **  (make-tab-bar PLACE)

> for now, suppose that PLACE can be a frame. In what I did, PLACE is only a
> frame.

OK.

> * TAB

> ** A TAB can be defined in many ways.

Could you mention at least the main ways?

> All tabs have in common a :NAME , and
> an :ID. :NAME is a string that is displayed on the display on the upperside
> of a frame, and :ID is a number that allows to user to easyly access it.
> Forget about :ID for now.

> ** A TAB also have an :INIT-CODE, a :ACTIVATE-FUNCTION, a
> :DEACTIVATE-FUNCTION, :CLOSE-FUNCTION:, hooks, and probably more.

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

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

> *** 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!

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

>> > But the :initcode can be very useful, because a tab should be
>> > re-initialized sometimes.
>> That sounds odd.  When would that be?
> It is very useful. Consider that you have a tab (like in EXAMPLE2).
> You keep in the upper window the buffer "xyz", and in down window the buffer
> "*scratch*"
> But 1 hour later, you need to keep in upper window the buffer "abc" and down
> "*scratch*". You need to re-initialize the tab, and the :INIT-FUNCTION will
> read again the value of "buffer1" and buffer2.
> Instead of deleting the tab, and creating a new tab of the same type (that
> switches to a buffer), you simply re-initialize the tab.

That should not be in the tabbar code, it can easily be handled from
outside, by providing a function to modify (rather than add) a tab.
Such a function would also be useful/needed in order to do things like
"add a * to the tab of a buffer that's been modified".

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

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.


        Stefan