>> The way I'm picturing it, the tab's internal state consists of four pieces
>>> of data: a title, a window (or possibly window configuration), a function
>>> that's called when it becomes active, and another function that's called
>>> when it becomes inactive. That *seems* like it's meeting all your
>>> requirements, as I've understood them.
>>
> The title must also a tab-local variable.
I've already pointed out that true tab-local variables would have nasty
consequences for critical code in Emacs, confusing the semantics of
variable lookup. Look at the sad history of frame-local variables and
their interaction with buffer-local variables for an indication of the
subtle problems you'll be inviting. (The problem is simple: if a buffer
and its frame *both* declare a variable to be 'local', which takes
precedence? There is probably code that depends on *each* taking
precedence, so any answer will be wrong.)
Now a list of 'tab parameters', like frame parameters, which have to be
explicitly looked up when needed, is more likely to be accweptable.
Please follow the previous messages; I pointed the fact that tabs could be conceived as object oriented system.
If a tab needs to create a process, it needs to keep the process variable TABPROC somewhere. This 'somewhere does not belong to global env, but to a tab-env.
The system will never see the variable TABPROC.
The variable tabproc is evaluated only by the callbacks associated with the events of the tab.
Only the callbacks of the tab need to evaluate that variable.
Frame local and buffer-local works on another env which is accessible to Eval, so to global env. In object oriented, the envs are separated.
For me it is clear that we will never agree on a common solution . The conclusion is that only 1 person will have to write the code for console/gtk/athena/motif. I can write it, and need to read the manual of motif and athena. I know GTK at beginning level.
I will not be abe to cope with this problem in the near future.