bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#10348: 24.0.92; Save and load window states


From: Stefan Monnier
Subject: bug#10348: 24.0.92; Save and load window states
Date: Thu, 22 Dec 2011 20:03:04 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux)

> (1) Do not save the `clone-of' parameter.  It's not yet useful anyway.
>     This will not solve the more general problem mentioned above.

As mentioned, it's not a really convincing solution.

> (2) Do not save window parameters.  While this should fix all problems
>     in the context of this bug report, it will prevent us from saving
>     and restoring information needed to make applications work that rely
>     on window parameters.

This is fairly attractive, tho a bit too radical.

> (3) Save only parameters whose value have a read syntax.  This can be
>     done either in `window-state-get' or in `my-save-frame'.

This can make the save&restore work and fail in somewhat
unpredictable ways.  Too magical.

> (4) Convert parameter values to something with a read syntax.  Basically
>     this is what we already do with buffers (using the name of the
>     buffer instead of the buffer object) and can be easily done with
>     windows (save the window number instead of the window object).

This would be a good change, especially if by "window number" you mean
a number meaningful in an output file rather than only in the current
session (see Juri's example) but it doesn't fix all cases.

> (5) Make functions like `my-load-frame' aware that components of saved
>     window states might not have a read syntax and have them take the
>     appropriate action.

This is like (3) except the magic is done elsewhere.

> Unless you have a better suggestion I'll apply (1) for Emacs 24.1 and
> try to propose a combination of (3) and (4) for later releases.

I think the best course of action is to only save the window
parameters listed in some variable (window-state-saved-parameters?).
Adding some of (4) would be a good additional refinement.

Actually, it might even be good to filter which params to keep not just
when saving but already when constructing the window-state object (some
params may simply not belong in a window-state object because restoring
them would make no sense).  After all the window-configurations don't
save&restore window parameters.


        Stefan





reply via email to

[Prev in Thread] Current Thread [Next in Thread]