Re: Fwd: Tabs for console.

[Stefan Monnier]

>> >> Where is it?  In the frame's parameters?  Or is it accessed via a new
>> >> frame-tabs and set-frame-tabs?
>> >>
>> >> struct frame
>> > {
>> > ...
>> >     /*
>> >      * an alist  of the form ((alist_tab_parameters))
>> >      */
>> >     Lisp_Object tab_bar_items;
>> > ...
>> > }
>> 
>> So it's not in the frame's parameters: how is it accessible from Elisp?
[...]
> So far it is accesible via frame-parameters, but in my code this access is
> not useful/used.

IIUC it is also (write-) accessible via `make-tab', right?

> I could separate all tabs parameters into a struct tab, and keep inside
> struct frame only 3 fields.

> struct frame
> {

>    bool subscribe_to_tabs;
>    int tab_bar_lines;
>    char *regexp;
> }

I don't care about such details for now: I'm concerned about the API it
presents to Elisp.

> Yes, like this. Or the :initcode is executed from (make-tab, like in my
> example, and for my example there is no reason to keep it memorized as a
> parameter in tab's alist parameters, because in this example it is not
> useful any more).

I'm still very far from understanding what you mean.
So here's how I imagine things working:

- some function to add/control/create a tabbar.
  (make-tab-bar PLACE)
  IIUC this function also accepts an INIT-CODE argument, which is run
  when the user presses the "+" button on the tab-bar.
- some function to add a tab to a tabbar
  (make-tab TABBAR ACTIVATE-FUNCTION DEACTIVATE-FUNCTION)
- probably also some function to delete a tab (delete-tab TABBAR TAB)
- probably also some deletion-hook in case the user presses the "X"
  button to delete a tab.

Now, all of ACTIVATE-FUNCTION, DEACTIVATE-FUNCTION, and DELETION-HOOK
could either be specified in make-tab or in make-tab-bar, depending on
whether we want to impose a uniform behavior.

If the ACTIVATE-FUNCTION is shared by all tabs, we'll also need each tab
to have a DATA argument, which is the equivalent of your environment.
  
> But the :initcode can be very useful, because a tab should be
> re-initialized sometimes.

That sounds odd.  When would that be?

> Yes, one can store private data, but if we need more private data than a
> variable, we need to name every stored value.

That doesn't matter to the tabbar code: the tab only ever needs 1 chunk of
private data passed to the activate-function.  That chunk can be
anything the activate-function needs: a struct, a list, an alist, you
name it: the tabbar code has no business looking inside.

>> Yes, the symbol `sym' assigned by `setq' above is a global variable.
>> It is assigned a value which is itself a symbol and that symbol is
>> indeed uninterned, but I'm talking about the symbol `sym' not about the
>> value stored into its value cell.
> This is a mistake in my code, it should not be . I forgot to call  a
> (make-unbound 'sym)

That doesn't solve the problem: it still affects the global variable
`sym'.

> ya, in my code I called the symbols tab:activate, and in messages I wrote
> :activate. Sorry.

No, you didn't write :activate, but :activate-code.  Such vagueness
makes it very difficult to figure out what you mean.

>> The tabbar code doesn't need to care about what that value is, it just
>> needs to store it and pass it along; the init-code and (de)activate
>> functions will decide what to do with it.
>> It can be a window-config or anything else.  That should make your
>> environment business unnecessary.
> Yes, if it is only 1 value, we know that it is on the first position of
> private-data list, and can access it via cadr.

"we" here would be the activate-function, right?

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


        Stefan