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

[Ken Hori]

Juri,

Could we add as an extra `buffer-file-name' alist element in the sexp
of a window-configuration or is that a bad idea? (I was just tring to
reconstruct a window-configuration after an emacs reboot but quickly
found out filenames weren't just there.)


On Sun, Apr 25, 2010 at 11:33 AM, Juri Linkov <address@hidden> wrote:
>>> ... 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/
>
>
>