Closed wasamasa closed 9 years ago
Another thing to take in account is that the current default of a new frame getting a completely new set of window configs would be challenged. It would for instance be possible to have a global list of window configs and a new frame sharing the window configs of the old frame (and inserting a new window config for displaying it). Such behaviour should obviously be customizable to emulate all kinds of window managers.
As I couldn't find any usage bugs and serializing to disk works well in combination with desktop.el, I consider this issue closed. Anyone depending on the structure of the window configurations needs to adjust it, the extra features can be dealt with in separate tickets.
It appears that I don't need to use
current-window-configuration
andset-window-configuration
(which are defined in C and use opaque window configuration types). Using(window-state-get)
and(window-state-put my-window-state (frame-root-window))
seems to yield similiar results.The difference seems to be that asides from the implementation language (the latter is implemented in Emacs Lisp) the former is frame-centric and the latter window-centric. The sources suggest that this will result in things like the menu bar height not being saved.
The benefits of using these functions would be: