Re: Gtk tabs in emacs, new branch

[martin rudalics <rudalics@gmx.at>]

 > ... Currently the design
 > is at the stage of deciding what format is better to represent the
 > window configuration.  There are two options: a window tree and
 > a plain list of windows.  I am inclined to the second option
 > since when saved it would be more compact.

There's absolutely no need to make window configurations saved by
`current-window-configuration' (I call them CWCs here) and window
configurations saved for later reconstruction in a possibly different
session (called EWCs) save the same states of things.

CWCs are needed to restore the appearance of a frame after a short
excursion or because some error occurred.  They are heavily overused in
that respect (for example, every time you drag a window's modeline with
the mouse up or down by one line, Emacs saves and discards the current
window configuration twice) but certain aspects might be needed to keep
the appearance coherent like, for example, `hscroll' related entries.

EWCs should IMHO strip window configurations to the absolutely needed
bare minimum.  In particular `orig-top-line' and `orig-total-lines' do
more harm than good in EWCs (BTW, I've completely done away with these
in my rewrite of window.c) as all other minibuffer related information.
Also hscroll and min-hscroll should not be stored.

Whether margin, fringe and scrollbar information should be stored in
EWCs depends on whether the appropriate settings for frames and the
buffer local values are stored and orderly processed as well - otherwise
they make few sense.  I'm afraid we'd have to store/restore all of them,
although I'm also quite sure that hardly anyone could tell how their
final appearance on screen is determined.

Coordinates should probably be rather stored as fractions instead of
absolute lines and columns.  This would make it easier to (1) eventually
switch to pixel based coordinates and (2) put an EWC into an Emacs
window (that is, put an Emacs frame into an Emacs window) as some IDE
advocats mentioned earlier.

Since I suppose you're running `split-window' to restore configurations
you'd probably also want to remember whether a "split" was a vertical or
a horizontal one in EWCs.  Note that CWCs don't do this since they need
to restore the configuration from the stored "coordinates" anyway, but
the design is a bit awkward as code like

  if (EQ (p->total_cols, XWINDOW (w->parent)->total_cols))

in `set-window-configuration' shows.

That said, the *entire* coordinate information of a particular window in
an EWC would consist of (1) whether it is a horizontal or a vertical
combination and (2) the proportional space - either a float or the
fraction of "some largest integer" - occupied by the window wrt to its
parent window.  Anything else would be pure overkill.

BTW in the earlier example structure you posted here I'm missing entries
for window-point, window-start, ...  Was that intentional?

martin