> The tabs should be a defined as a list of objects (of type 'tab) in the
> struct frame.
Why do you want to introduce such a restriction? If people want to
specify tabs on a window- or buffer-local basis they should be allowed
to do so.
I did not think to this important aspect.
> Other example: a tab that switches to a buffer assoc with a file, like
> /root/.emacs
>
> - initialization event is defined so:
>
> -- erase all windows, and keep 1 window ( delete-other-windows )
This is an example where frame-only tabs are hardly useful. Switching
to a buffer should not delete other windows.
This is how I defined the tab. If you do not want to delete a wndow, you write a different elisp code.
> -- memorize window configuration into a variable 'OLD-window-config
> inserted in the assoc list of the tab
This is an example where associating tabs with frames seems useful.
This makes no sense alone ; it is in connection with the same tab . This is just other event for the same tab.
> Note that it require not too much work at C level, and it gives a huge
> number of possibilities of defining tabs, exactly as the 2 principles says.
In which sense do your tabs differ from menu or toolbar elements? You
can easily add a menu element to save the current window configuration
or pick one of a list of earlier saved configurations to restore that.
You cannot at all define menu or toolbar buttons which respond to standard events , at which tab widgets shoud respond.