>
>
>  > It is evident that the problem of tabs passes beyound the limits of
>  > graphical capabilities of emacs.
>
> Not at all.  Lack of graphic capability has nothing to do with it;
> graphically adding tab control widgets is no problem (I'm looking at
> them in my XEmacs right now), and displaying different content in the
> same window is Emacs's bread and butter for user multitasking.
>
>
The effort you depose to write tabs for emacs can be compared with the
effort to add to emacs a real graphical interface -- this require maximum 5
000 lines of C code.

And if this is done, we will have a graphical interface of the same power
of that one of smalltalk.

Or otherwise -- a smalltalk with an editor with editing capabilities of
emacs.


The problem that you face is that nobody else understands why you
> think it necessary to add a whole new event processing system to Emacs
> to support your tabs, or why you think tabs are an appropriate
> graphical metaphor for subprocess control (beyond what can already be
> accomplished by attaching the process's stdio channels to a buffer,
> and switching to that buffer via tabs).
>
>  > To add morphic objects to the actual structure of emacs it is also
> beyound
>  > the limits of the system.
>
> Again, XEmacs did so a decade ago, by the name of "native widgets".
> They are not used much (partly because Emacs doesn't have them, so
> third parties avoid using them, and partly because the developers who
> introduced them only debugged their itchy applications, so they tend
> to still have bugs that need serious scratching when you try to use
> them for other applications), but they are surely proof of concept.
>
>
This is a play. This graphical interface is limited to the capabilities of
emacs's matrix of glyphs.




>  > Having such a structure, emacs will have a main working desktop -- main
>  > morph, in which we can drop other kind of morphs -- like buffers, tabs,
>  > etc. (the frames will not be useful any more).
>
> I think you need to rethink your basic concept of "morph".  Buffers
> are *not* GUI objects, and should not be.  It is important that a

buffer be displayable in more than one place, or completely detachable
> from the UI.  It's arguable that a tab control is a generalization of
>

A buffer could be displayed in 2 morphs , if you want.

Just start reading about the basics of oop and the link with graphical
interfaces.

Seems that you never heard about morphs:

http://en.wikipedia.org/wiki/Morphic_(software)