Investigate into `window-state-put` and `window-state-get`

[wasamasa]

It appears that I don't need to use current-window-configuration and set-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:

• Having inspectable states
• Having states that are not bound to a specific frame or in other words, can be applied to any frame and therefore allow sending window configurations somewhere else
• Having serializable states, the currently most obvious deficiency of this package as compared to the alternatives.

[wasamasa]

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.

[wasamasa]

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.