Re: Gtk tabs in emacs, new branch.

["Stephen J. Turnbull" <stephen@xemacs.org>]

Juri Linkov writes:

 > > Cnsider the GIMP's tab docks - You can have a layers window, channels
 > > window and paths window (not the gimp terminology, they actually call each
 > > window a "tab") docked into a tab group or a  brushes window, layers window
 > > and palette window.  Or whatever.  And rearrange them as you see fit.
 > 
 > I don't think it's right to call these things "windows".

That depends on the implementation.  Almost certainly, though, each of
these is actually a GUI widget, which is more or less equivalent in
Emacs terms to a window dedicated to a buffer.

 > A "window" in Emacs is the physical area of the screen in which a
 > buffer is displayed.

That's a restriction of Emacs, not of the concept of window, though.
Emacs is effectively a tiling window manager (within each frame).

 > So they are rather a layers buffer, channels buffer and paths
 > buffer.

This on the other hand is definitely not the case.  The GIMP's tabs
are indeed tightly bound to screen regions, whatever you want to call
them.  They are not conceptually independent of the screen, as Emacs
buffers are.

 > Another variant is to call them "window-subtrees",

The use of the word "call", suggesting that the underlying
implementation is the same, is misleading.  As you and others have
pointed out, in Emacs there are at least four different ways to
implement the usual tab behavior: (1) one Emacs window, clear and
rewrite the content of the associated buffer (eg, the echo area/
minibuffer); (2) one window, move point in the associated buffer
(bookmarks); (3) one window, switch associated buffers; and (4)
multiple windows, delete a window and restore another in its place.
(Here I use "Emacs window" in its general sense of a window tree,
which may be split horizontally or vertically.)

So far the only interesting argument I've seen against a general
callback implementation supporting any and all of the above, as well
as others my marginal imagination is insufficient to contain, is Jan's
claim that it results in flashing and a race condition.

In XEmacs, which implements its tab control widget with a generic
callback into Lisp, I admit that I do see flashing in builds with
Lucid toolkit and a homegrown tab control widget (based on Edward
Falk's free widget set available on the 'net, but heavily modified;
don't blame Ed!)  However I claim that this is a bug in our redisplay;
if you have a sufficiently slow X connection, you can see the tabs (in
fact the whole window) being redrawn multiple times as the result of a
single tab press.

In the ten years that we've had the tab control, I can't recall a bug
that was diagnosed as a race condition in the tab control.  So maybe
that's a problem for GTK builds, but GTK getting in the way of the
app's design is nothing new.