[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fwd: Tabs for console.

From: Alin Soare
Subject: Re: Fwd: Tabs for console.
Date: Fri, 10 Dec 2010 10:15:47 +0200

> :INIT-CODE must be run to get some values that are useful for

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 )
   (let ((buffer1 (car data))
          (buffer1 (cdr data))
   (switch-to-buffer buffer1)
   (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.

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]