Window configurations (was: Gtk tabs in emacs, new branch)

[Juri Linkov <juri@jurta.org>]

>> ... 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.

Yes.  That's why I added a new argument `live-p' to
`current-window-configuration-to-sexp'.  When non-nil, it adds live data
(window objects, buffer objects, markers, etc.) that are necessary
when its Lisp expression will be used in the same session.  When nil,
it returns bare minimum necessary to save and restore in another session.

> 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)

Do you plan to create a branch for your rewrite of window.c?
It would be very interesting to look at it.

> 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.

There are no problems with storing coordinates as absolute lines and
columns.  After restoring absolute coordinates `set-window-configuration'
resizes the frame thus keeping original relative sizes unchanged.

> 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.

No, I don't use `split-window'.  I use exactly the same algorithm as in
`set-window-configuration', and additionally make new windows.
In my tests, this works correctly.

> 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.

Currently `set-window-configuration-from-sexp' works without these
parameters.  But maybe they would be useful for user-defined window
configurations.

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

There are entries `pointm' and `start' in the output of of the really
working function `current-window-configuration-to-sexp'.

But the example of the output of `window-configuration-to-sexp' is for
demonstration purposes only.  It doesn't work yet, because I'm not sure yet
whether it's better than `current-window-configuration-to-sexp'.

-- 
Juri Linkov
http://www.jurta.org/emacs/